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

mailinglists at geldenhuys.co.uk mailinglists at geldenhuys.co.uk
Sun Apr 5 00:13:58 CEST 2026


Hi Florian,

On 2026-04-03 19:21, Florian Klämpfl via fpc-devel wrote:
> - they are often not fully tested for all border cases (architectures, 
> platforms etc.), if I merge them, I am responsible to fix broken things

If a merge breaks something, you can simply revert the MR and notify the 
author. GitLab makes this very easy. Since the "main" branch is intended 
for development, most people don't expect every MR to be perfect 
immediately. If you do expect perfection, I'm afraid you are in the 
minority. Once merged, code receives significantly more testing—even if 
only from the few who use the "main" branch daily.

The "git" repo itself uses a special branch where MRs are reviewed and 
merged for testing before moving into the release-candidate branch. 
Since FPC doesn't have the same volume of traffic or developers, using 
the "main" branch for this purpose makes the most sense.


> - some are dubious regarding code style/approach

If "code style" refers to formatting, FPC already includes its own 
formatter — it’s just that the configuration is incredibly confusing. I 
tried using it for my recent OPDF code, but the output looked nothing 
like the rest of the compiler source, so I reverted the changes. You 
could implement a pre-commit or pre-merge hook in Git to run a formatter 
automatically, but it requires a clear set of rules.

Speaking of which: I recently asked about FPC's code formatting rules so 
I could adapt my MR. It seems there isn't any accurate documentation. 
The wiki page suggested was quickly debunked as outdated or incomplete. 
Currently, the "formatting rule" is essentially just: "Look at the 
surrounding code and try your best." :shrug:

> Multiple reasons:
> - it’s a boring job

Automation is the answer here.

> - fpc releases require an awful amount of handwork like updating 
> version numbers in multiple files like readmes, whatsnew, utils etc.

This is extremely simple to automate. You can even use AI to help script 
it. You don't have to spend money; just use Gemini’s CLI with a free 
Google account. It can handle these updates in a fraction of the time a 
human would. At my workplace, we’ve automated almost every laborious 
task using AI — it's incredibly effective at it and allows developers to 
focus on the fun part: writing code.


> - tracking progress is documented in the wiki, another pain

For fpGUI and PasBuild, I let AI do the work. I used to maintain a 
changelog.txt manually, but now I just have AI scan the Git repo between 
two tags. It does a brilliant job, even generating migration 
instructions for breaking changes. Use AI as another tool in your 
developer toolbox; it's a massive time saver.


> - FPC repository structure directly converted to git make working with 
> it a nightmare: git sub modules reference to a certain revision,

I agree — Git submodules have been a pain since they were invented. 
There are much better alternative solutions available today.

Regards,
   - Graeme -


More information about the fpc-devel mailing list