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) _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
