[fpc-devel] [RFC] Modernising the FPC Release Process -- Proposal for Review

[Marco van de Voort]

Op 16-4-2026 om 11:29 schreef Michael Van Canneyt via fpc-devel:
>
>
> Every time the build or release is discussed, all I hear practically 
> amounts to "the problems are insurmountable". That is why I term it 
> negativity.

To my best knowledge something like that has never been said. You might 
interpret failure to embrace your proposals as such, but that is not the 
same thing.

I have reiterated my main points for nearly 6 years now:

1. the building is currently not the bottleneck. Yes, it can be brought 
back from a couple of weeks for the first RC for a fixes releases, and 
roughly two months for a major release, but even if you could automatise 
that to zero (which you can't), it does not fix the current _AND_ past 
release gaps.    You also do not need CI infrastructure for that, 
quarterly attempting to build relevant targets.  The problem will always 
be the human factor, ALSO to investigate and take action on those CI 
builds.   And a fact of life is that if the infrastructure gets more 
complicated, less people are prepared to deep dive into it to actually 
do that.

2a. The major bottleneck is chiefly  branching and releasing major 
releases.  Waiting on features to stabilise takes ages. Those ages are 
waiting for people to fix it. You can try to avoid to merge unstable , 
but as I hope you have found out with the loadppu branch that is not 
always  an easy thing.

2b. Fixes have their own problems, but those are all actually getting 
people to move.   If there is the shared consensus to release a fixes 
release, and continuous merge process have occurred (as the current 
fixes branch , it could be done in 6-12 weeks, depending on the number 
of needed RCs, and the nature of the feedback on them. That is a full 
minor release cycle, checking all the boxes, no shortcuts.  Even with 
many targets beyond Tier 1 in the mix.    We currently have a 5 years 
minor release gap., 6-12 weeks is nothing on that scale.

3. Do changes gradually as you get experience. No big bang, no drama, no 
longer delays while infrastructure and policies get worked out. Start 
some CI work if you want on the side, follow up with high frequency, and 
see if it works, and people actually use it. Pace changes.

Keep in mind that in the release sense we haven't fully managed the 
svn/mantis to gitlab transition, 5 years after the fact. And you want to 
toss in more infrastructural work ?

> My sincere hope is that by putting some different structure in place, 
> things
> will go smoother. If we need to let go of some practices from the 
> past, then
> that should be possible. 

The only past practice that you could let go that saves a real 
bottleneck, is actually caring about what goes into a release. But then 
you get back to the snapshots vs release point that I made.

Automating building and branching is all fine and dandy, but the problem 
is to actually get content (read: merged revisions) in those branches, 
and your proposals are awfully quiet about that. It sets a few schedules 
and rules (that basically are an toothless appeal to developers "to 
think about the releases and do the merges", but all developers could 
have merged all their commits in the current situation already, so what 
effectively changes).

You are trying to fix a basic problem (no people actually doing 
something) with lots of high level rules and infrastructure that is 
copied from large scale projects that allows managers to track progress 
of the grunts. IMHO it simply doesn't make sense in a FPC volunteer context.