[fpc-devel] 134 open merge requests - is that normal?

[mailinglists at geldenhuys.co.uk]

On 2026-04-03 09:17, Michael Van Canneyt via fpc-devel wrote:
> 
> I consider it by no means "normal".
> 
> But verifying takes time and we're dramatically short on manpower.

That does seem like an awful lot of changes (improvements and fixes) 
just sitting there in limbo.

If it's burnout, I fully understand that too. I went through that, along 
with a career change, and took a six-year break from the fpGUI project. 
Recently I returned, and I felt so motivated to complete my outstanding 
to-do list. I managed to do more in these last six months than I did in 
the previous six years!

I must say, I was also very surprised after I returned to see no FPC 
releases in five years—not even a fixes release!

When you say "short on manpower," are you referring to those developers 
who have commit access but aren't doing code reviews? Or are you 
suggesting that the community is not helping?

If the latter, how can I (we) help? I'm more than happy to help with 
reviewing, but I don't want to do that if FPC developers will simply 
ignore such 1st-pass reviews regardless.


On a side note:
---------------
One thing I've realised with fpGUI and PasBuild is that I used to go 1–2 
years between releases (in the case of fpGUI) because I wanted 
everything perfect. But I suffered from feature creep—"just this one 
more feature," then that, then another. The reality is that hardly 
anyone tests "in-development" branches, so the feedback cycle was near 
zero. I always had to create "maint" releases too, which was even more 
work for me.

I've since switched to time-based releases. Think of it as a "train 
schedule" release cycle. Freeze a release branch one or two months 
before the release is due. Whatever features didn't make it in before 
the freeze will just have to wait for the next train—say, in six months 
when the next release happens.

This also means more people will use the releases, leading to wider 
testing and better feedback. (Lean on the community!) If feedback isn't 
great, improvements will come in the next six-month cycle. If a critical 
issue pops up—which should be rare, assuming the test suite caught the 
big ones—then make a hot-fix release just to patch that specific issue.

We are all developers here, so releases don't even need installers or 
anything fancy. Simply a source archive or a Git release tag with a 
README explaining how to build it yourself.


Regards,
   - Graeme -