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

[Martin Frb]

On 07/04/2026 16:21, Tomas Hajny via fpc-devel wrote:
> On 2026-04-07 15:58, Martin Frb via fpc-devel wrote:
>> On 07/04/2026 15:41, Martin Frb via fpc-devel wrote:
>>>>>> 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!
>>>>>
>>
>> Actually, I would think the relation between fpc src and build can be 
>> described as n to 1
>
> Not really? Most changes in fpc-build don't depend on changes in 
> fpc-src (at least not directly) and vice versa? However, you need to 
> have both parts up to date when building (either a release, or a 
> snapshot, or whatever - depending on the particular branch).

Ok, then I got that part wrong. So then maybe its to adapt to changes in 
OS, make, ....

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

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.


>> But because the submodule in the current direction, allows to specify 
>> only one fpc-source commit as belonging to the fpc-build commit, you 
>> artificially keep creating commits, so you can link to all the other 
>> fpc-source commits.
>>
>> And if you reverse the dependency, that should disappear. You only 
>> need the submodule update, when it is technically required.
>
> No, because you loose the consistency then. You wouldn't test RC 
> building, etc., against a clearly defined state, and you wouldn't know 
> what people used when they report issues.
Sorry, but I don't follow?

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?


>> If the dependency order is swapped, and you commit to fpc source and 
>> it keeps building with the same fpc-build, then there is on submodule 
>> update needed.
>
> Again, during the release (and their preparations), changes are 
> performed in both (actually, all 3 including fpc-docs) repositories 
> and you need to keep track of the latest (most up to date) state of 
> both / all 3.

But the time at which those changes happen, does it really matter. So 
long as for any give source-commit there is a specific build-commit. And 
that specific relationship can be found for the rest of time?