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

[Marco van de Voort]

Op 7-4-2026 om 13:13 schreef Michael Van Canneyt via fpc-devel:
>>
>> It is an organised endeavour, not a mindless robo-act.
>
> We're talking about building a release at regular intervals.

The fixes branch as is yes. And I said that the problem is making sure 
things to be released *are* in the fixes branch.

>
> If we limit what goes in, testing will be reduced to minimum, making it
> perfectly doable.

Current minor releases are also doable. It just needs to be done.   With 
the same attitude as now, that leads to empty releases just because the 
timer ticks.  The work overhead per actually delivered fix to the user 
only increases.

> If of course we mindlessly merge in whatever pops into our head, we're in
> for a bad ride.
>
> That a major release is more complicated does not diminish the value of
> regular releases for the user in any way.
>
This was basically the situation before I started working on releases in 
2.0.4 times, and it doesn't work.

Making fixes releases with a handful of emergency fixes, only wides the 
gap between fixes and the next major release even more, which results in 
unusable .0 releases and you still don't resolve most the frustration 
with the current scheme.

Namely that users have to wait a long time (till the next major release) 
before they see a fix back in a release.

Just saying that you have recently essentially rebuilt the last release 
with a few fixes won't make that go away.

The problem is the human factor, not policies or build technology, but 
actually executing the policies and using the tools that are there. Time 
based or old style doesn't matter.

If you manage to accelerate that (and more often releases leads to more 
polishing of the details of the process), you might actually change 
something with the release schedule. Pinning all your hope on near empty 
robo builds to circumvent the human factor won't.