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

[Marco van de Voort]

Op 15-4-2026 om 15:18 schreef Graeme Geldenhuys via fpc-devel:

(warning: this will be harsh, as I'm increasingly getting fed up by 
these gratuitous "release process" designers)
>
> The central idea is a "Release Train" model: releases depart on a
> fixed schedule regardless of which features are ready, removing the
> "just one more thing" pressure that has kept us in freeze. The
> document covers:

It is the exact opposite of my central idea. Which is "More release 
workers, less release workflow designers". Specially not workflow 
designers that never took any responsibility for the release project before.

The problem is not drawing up elaborate release plans. The problem is 
_executing_ them. We have heard all of these suggestions before, and 
yes, like yours, the proposals typically they originate in workflows of 
either professional or high profile open source projects that share the 
existence of release engineering FTEs, branch managers etc . (either in 
the project or the project sponsors).

That is _pointless_ comparison. You want to compare release process? 
Pick a wholly volunteer driven grassroots project as model, and forget 
about the dramatic effect of how big projects do it.

Anyway, till the current hiatus, the primary problem was the gap between 
the minor releases and the next major release (the x.y.4 release was 
often a stopgap to hide the delay of the next major branch). That holdup 
was mostly related to major features that are not stable nor finished, 
and promises to fix them not making any proposed deadlines. Then what do 
you do? Ship an unusable project to meet artificial deadlines ?

Your plan does not contain any suggestion to fix such scenario. It 
ignores trunk having been unstable for 1 1/2 years, and only now slowly 
getting past the PPU rewrite. It skips over any causes for the holdup 
for the fixes release, instead only suggesting skipping/ignoring it, 
while the .4 releases are the most longtime used versions of them all, 
and without checking if a next major fixes branch is viable.

it seems to assume that a few unusable robot generated releases will 
provoke people into action. It won't. If a 5 year release hiatus won't 
make people move, an artificial timer ticking down half an year from now 
won't either.

None of your ideas are new. It's a amalgam of a technocrat's knee jerk 
reaction (*) without really studying the problem, hoping that some 
magical structure will "motivate" the grunts doing the work.

The problem is that there are /no/ or few such grunts. And the few that 
are there don't like to be told what to do by people that never walked a 
mile in their boots.

To anybody that wants to fix the release problem: be a manager for a 
full major cycle. Then you can redesign the process. Not before.  And 
yes, that includes you, Michael.

P.s. the increasing merge requests is a partially a problem created by a 
fundamental flaw of git merges .   People can work much longer on their 
own before communicating over pushing it upstream, which leads to 
complex and hard to merge branches.

Combine that with the unfortunate FPC policy of not immediately closing 
hopeless or far out feature requests, and you get a backlog in both 
merges and bugreports.  Increasing reports is at least partially a  
normal consequence of a lax closure/reject policy, because when in 
doubt, reports/MRs are left open.

(*)  I only miss the only somewhat useful suggestion to tier platforms, 
so that relative minor platforms can't obstruct a final release. That 
has already been agreed upon though after 3.2.2, but never got executed 
due to the current hiatus.

(breathes out)