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

[Michael Van Canneyt]

On Fri, 3 Apr 2026, Florian Klämpfl via fpc-devel wrote:

>
>
>> Am 03.04.2026 um 19:56 schrieb Graeme Geldenhuys via fpc-devel <fpc-devel at lists.freepascal.org>:
>> 
>> 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.
>
> Problems:
> - time to review properly
> - they are often not fully tested for all border cases (architectures, platforms etc.), if I merge them, I am responsible to fix broken things
> - some are dubious regarding code style/approach
> - some are language extensions where there is no consent if it’s useful 
>
>> 
>> 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!
>
> Multiple reasons:
> - it’s a boring job
> - fpc releases require an awful amount of handwork like updating version numbers in multiple files like readmes, whatsnew, utils etc.
> - tracking progress is documented in the wiki, another pain
> - FPC repository structure directly converted to git make working with it a nightmare: git sub modules reference to a certain revision, so when something is updated in a release branch of fpcsrc, the „super“ module (i.e. fpcbuild) needs an update as well, makes working very messy. In principle sounds doable, in practice one messes up permanently, in particular when working on multiple machines and with multiple repositories.
> - lack of time

Amen to that.

3 suggestions to reduce the pain:

- script/code the version change stuff (But I know you're working on that already)

- Repo structure: probably it is better to use git subtree. It's meanwhile well established.
   It corresponds more to what we need, I think.

- Track progress:
   I think having an milestone/epic and a task list in gitlab could be helpful.
   In that case multiple people can work on it and it would be fully tracked.
   We could even accept merge requests for it.

If I can help with some of these things, please let me know.

Michael.