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

[Marco van de Voort]

Op 7-4-2026 om 11:01 schreef Martin Frb via fpc-devel:
>
> 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).

For me it is about the same, if you don't count that merge tracking was 
not out of the box, but crafted by Florian with scripts and a 
requirement to merge with -x.  That took over an year to gestate, and 
has been down for periods.  Still, it is workable. I still have to build 
a filter for the fpcbuild repo, something I planned for the coming 
weeks, now that I have more time again.

As far as merging goes I'm not as versed in solving if something goes 
wrong with GIT as with SVN, so I shy away from the larger merges, but 
that will improve a bit with time, with some unresolved cases remaining 
(GIT can simply go wrong more easily and is more complicated in general)

But I currently can't branch a release branch from fixes and maintain it 
while last minute fixes are delivered. Same but worse for creating a new 
fixes branch. That's why I stopped being release manager in 2020, and it 
is still true.

> 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. 

Yes. But that could have been done both with past SVN or current 
git-with-patchy mergetracking. It simply doesn't happen.

That is the whole problem with all these fantasies (the git migration 
inclusive), they paint an ideal sunny upland, and then try to simplify 
the whole issue to "if we just cross this bridge, the problems will be 
gone away". But the devil is in the details, and it is usually the human 
factor. The big changes are only goal posts to nail policy too, they 
don't solve anything in itself.

To be fair: merging in the compiler is harder than what I do , since 
things are more interconnected there.

> 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's what I still do occasionally, merge a large section of the non 
compiler revisions in order. Currently around a x.y.4 point that gets a 
bit harder, and certain categories are not merged at all.

In the past it was mostly intertwinement of must have new mysql 
connectors with fcl-db restructures.   In this cycle I ignore nearly 
everything "web" related categories (fcl-web/js/json, fcl-passrc(due to 
pas2js) and many, many more packages that I hardly know) because the 
very high number of intertwined revisions, and a lack of overview of the 
status of these packages. I assume only Mattias and Michael know 
anything about them.

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

Yes. And it happens. Sven, FPK and Jonas all merge some of their revs. 
But at a very, very low rate, and mostly really short revs only.  I 
think only Pierre might fit the description better.

>> Florian already mentioned the submodule problems.
>
> Leaves the question why they are not re-organized.

Because we were told that git solves all problems and can do everything 
(;-)).  It was all so simple and modern, and contributors would 
magically appear from all corners of the internet, and pink unicorns 
would run through its streets and fart perfect code. (ok, I made that 
last bit up)

However during the year before the migration very few of the identified 
problems were solved, except merging pre SVN era history to form a 
large, mostly continuous history.

Submodules, merge-tracking, nothing was ready when the transition was 
forced through, and at a very late point (when migration to GIT changed 
to migration to gitlab, the bugtracker was also thrown under a bus).

A workaround solution for merge tracking took another 1 1/2 year. GItlab 
only allows to save views on the bugtracker for a few months now.

Merge requests, that were hailed as the magic bullet that would speed up 
the pace of development.

Well, merge requests is  the original subject of this thread. One can 
argue if they are a netto plus or not, but there are downsides too (it 
allows users to submit more code at once and without prior communication 
to core about formatting and other decisions), and in any case they are 
not the game changer they were hailed to be.

(I think they are a netto plus, but a rather small one)

I assume that some changes were also postponed to the next release round 
(i.e. pacing the gitlab changes), not realising the gap that would 
build. The same happened with the SVN migration.

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

fpcsrc is roughly the shipped source archive, fpcbuild is everything 
else + the other submodules like documentation.

But fpcsrc and fpcbuild both need to be mergetracked. Documentation 
afaik isn't,.

Maybe some of the decisions were also influenced by gitlab limits on the 
number of repos if you didn't get the open source status.

> **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... 

See above, things were rushed through, and all details were deemed 
solvable with git(lab). Any opposition was ridiculed as the way of dinosaur.

Anyway, if we reverse the order, then if I understand everything 
correctly  we would have the robo commits to advance the fpcbuild 
submodule link in the fpc/ repo ? No thanks!

If I understand the problem laid out by Florian correctly, a sane 
solution would be more to have a new root repo that only has submodules. 
(fpcbuild , fpdoc, fpcsrc). Then the history of that repo doesn't matter.

But that would require some makefile and scripting rework in fpcbuild to 
handle the change directories.