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

[Martin Frb]

On 07/04/2026 10:41, Marco van de Voort via fpc-devel wrote:
>
> As said the prerequisites for time based releases are not furfullled 
> by FPC, where very little release related action happens outside 
> release periods when releases are being prepared outside of my bulk 
> merging of non compiler revs.
>
> Having time based releases would only have delivered 
> years/(frequency_per_year ) carbon copies of essentially 3.2.2. 
> Specially compiler bugs are hardly merged outside of release 
> preparation periods. (say a dozen out of 6000 compiler related revs 
> difference between main and fixes. Not all will be relevant in 3.2.x 
> context, but a dozen is very low bar)

First of all, I have no insight on the workflows of the FPC team... But, 
IMHO with git, this should (have) become easier.

Of course, not on its own.
And certainly not **IF** the merging is done by a small group (subset of 
the team).

But, with git everybody should become part of it. Ok, well not everybody 
will feel comfortable enough, but that is solvable, if at least half of 
the team has the "git knowledge" (and willingness).

Everyone should make a **pre**-selection of their own commits in terms 
of merge or not. That hardly takes time. And (very most likely) whatever 
current system is in place, can run from that pre-selection, with 
heavily reduced amount of work. (and less merge conflicts).

That may be to late for the current branches. But for going forward 
there would be ways.

> Florian already mentioned the submodule problems.

Leaves the question why they are not re-organized.

Except for some historical svn order, I never understood why FPC-Build 
is the top level, and fpc-source is a sub-module within.

**For an outside observer**, everything says that (if using submodules) 
then fpc-source should be the main repo, and fpc-build should be a 
submodule. Yes, I can see that the dependency can be argued either 
way... Anyway that isn't my call to make...