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

[Tomas Hajny]

On 2026-04-07 18:42, Martin Frb via fpc-devel wrote:
> On 07/04/2026 18:03, Tomas Hajny via fpc-devel wrote:

  .
  .
> I mean currently yes, but if the relation was the other way round, if 
> you could say
> Please test with fpc-src ABC123 => and switching to that would load 
> fpc-build FDE321 as submodule?
> Would that be worse?

No, it would be basically the same - except that you'd have to adapt the 
Makefiles to this change (and it isn't easy to do due to different parts 
only used on certain targets and thus not easily tested by one person).


> Yes, but see above. If the dependency order was changed, you could 
> still switch to an exact pair of the two.

Indeed.


> You just have to identify them by the fpc-src sha1, instead of the 
> fpc-build sha1.
> 
> As I see it, from all I gathered, for just being able to identify an 
> exact pair/combination => either way works. The current works, of 
> course it does. But switched also would work (well maybe I still miss 
> something).
> The questions is/are just
> - are there advantage by identifying the pair from the one or the 
> other?

No, the only advantage of not changing the direction is that you don't 
have to modify the Makefiles. Well - technically, you wouldn't have to 
modify it if you created fpcbuild and fpcbuild/fpcsrc subdirectories 
within the original fpc-src repository, and move everything from the 
original repository under the newly created fpcbuild/fpcsrc/ 
subdirectory (and obviously move the top-level Makefile from fpcbuild to 
fpcbuild/ in the fpc-src repository). That should allow keeping the 
Makefiles intact while changing the dependency direction, so this would 
be an option as well - if considered as an important improvement 
compared to the current situation.


> - would a monthly or bi-monthly "update" in fpc-src (and some during 
> release preparation) be worse or better than 3 per day on fpc-build?

_Much_ worse - basically unusable for the original purpose as already 
explained by Marco in his yesterday's response.

_If_ we need to make some changes in the repository structure and _if_ 
there's no (reasonable) alternative solution allowing us to keep the 
current layout by using a different Git technique (I'm by no means a Git 
expert), then I'd prefer either converting everything to a single 
repository (with the potential disadvantage / change of having fpcdocs 
branched as well and another disadvantage of having 3rd party binaries 
with FPC sources within the same repository). The idea of an empty 
top-level repository importing all three parts (fpc-src, fpc-build and 
fpc-docs) while keeping the original directory structure _and_ keeping 
the automated updates from all the three repositories (!) would be OK 
from my point of view as well, but I don't see how that differs from the 
current situation of fpc-src and fpc-docs imported to fpc-build - 
however, I might be overlooking something important.


  .
  .
> Of course if it really is ONLY for combining the 3 repos for release 
> build (including test builds of that) then you could have an empty 
> repo, that just has all 3 as submodules.
> 
> It would not have automated updates. Whoever want to start a release 
> build (from HEAD) will do one update, and can then ask others to use 
> the fpc-rel-group sha1 for their tests.

No, this last part wouldn't fit - again, see Marco's comments in his 
last e-mail yesterday.

Tomas