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

[Martin Frb]

On 07/04/2026 18:03, Tomas Hajny via fpc-devel wrote:
>>>> - For any commit in fpc-src there is one fpc build commit that 
>>>> works (others may, but one that should be used)
>>>> - For any commit in fpc-build there are many commits in fpc-source 
>>>> that it can be used with/for.
>>>
>>> It isn't just that it wouldn't build, but that you need clearly 
>>> defined combination you can refer to (should it be because you want 
>>> to test building and the point of the test is having a consistent 
>>> state to which the test refers to, or because you want to be able to 
>>> refer to a clearly defined point in time in the bugtracker, because 
>>> there _are_ some cases in which one depends on the other).
>>
>> But then that is the point I made, or isn't it.
>>
>> If you build FPC source SHA xxxx => then you must have FPC build => 
>> sha yyyy
>
> It isn't that you must have FPC build => sha yyyy (and it wouldn't 
> build otherwise), it is that you always _should_ have the most up to 
> date version of both. It's like saying that you must have FPC RTL >= 
> SHA xxx when building release of FPC compiler >= SHA yyy - while that 
> is true for certain versions, you simply don't want to include random 
> (although technically "valid") combinations of FPC RTL and FPC 
> compiler sources in the release process, because you want to be sure 
> that two people building the release should always use the same 
> combination. And if you want that for the release, you also want to 
> have that when testing the release building process.

Ok, but then you could update the submodule (with either being the main 
and the other the sub module) just before that time... Currently it is 
done several times a day. I would guess there aren't release related 
works or testing on the main branch at current?

And so then, right now (on the main branch) would apply to use the 
latest of both. Anyone can just check them out independently (or force 
their submodule locally)?

So why is that flood of "Update" commits happening.

----------------------
Mind, given the just keep the top commits together updating, even if it 
isn't currently in release...

Then yes, if you switched you would have similar commits in fpc-src. 
Except the last real commit on fpc-build is from February. So outside 
release cycles (and for the main branch, that would be always), that 
would mean one "update" commit every couple of weeks?

During releases, on fixes I take your word it would be more frequent. 
Still, would it hit 3 a day, almost every day?



>
>
>> But if you have sha build sha nnnn => then there are many fpc-build 
>> commits that could be build with it.
>> At least the fact that many otherwise identical fpc-build commits 
>> have all those different fpc-build commits would strongly suggest that.
>
> You probably have some typo there (fpc-build x fpc-build), but I hope 
> that I clarified the point above.
The question is, how to you find the matching pair...

Well for a release it is easy => you go to the tag.
The tag in fpc-build will be conveniently set such as it gets you the 
correct fpc-src too.
Of course then, if you go by tag, you could just have the same tag in 
both repo, and you would not need submodule relations...

But if you say, you tested with fpc-src ABC123 => and you ask someone 
else to test with the same...
How does that work, they can't just check out that commit, they need the 
fpc-build commit that is linked to it.
So they need to go to fpc build. They need to search the fpc build 
commit that will check out fpc-src ABC123....

Or (probably?) you never say, please test fpc-src ABC123 => instead you 
say please test fpc-build FDE321.
Is that more convenient to do all work based on the fpc-build commit?

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?


>>
>> If I would check out the fpc-source commit xxx tagged as RC1, then it 
>> would have an exact specified  commit in the fpc-build submodule? It 
>> would always be build with that, never any other?
>
> Yes. But preferrably, you want to be able to test that already before 
> tagging (remember - there are _many_ different targets and the target 
> maintainers should test their building even before tagging!), and also 
> after tagging (testing the release building after needed fixes coming 
> from the RC testing are applied).

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

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


>
> I'm not sure if I understand what you mean here. The point is to 
> provide anybody testing the release building (or performing the 
> release/RC build) with a consistent combination of all three sources 
> for the chosen branch at any point in time.

So fpc doc then also would need to be a submodule of fpc source.
Well, not sure nested submodule in fpc-build might work too, but has no 
advantage.

Question is how many "update" commits fpc doc then triggers.

I guess docs are updated independent of the changes that triggers there 
change (i.e. adding a property will not add the docs, the docs come later)?
Then the "update" of the submodule would only be needed when release 
testing starts?

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