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

[Marco van de Voort]

Op 16-4-2026 om 00:06 schreef Graeme Geldenhuys via fpc-devel:
>
> --- On people vs. process ---
>
> You are right that a document does not replace people, and I want
> to be clear that I am not suggesting it does. The proposal is not
> asking the existing team to do more work — if anything, the goal
> is the opposite. The triage labels, the CI green-light requirement,
> and the Squash mandate are all designed to make sure that *the
> author of each MR* does the preparation work, so that maintainers
> can review from a clean, rebase-confirmed, CI-verified starting
> point rather than untangling years of drift first.
>
That is still quite a big ask for something that will only proof itself 
to be right in a very distant time.

I would try to make major improvements and changes that you can't manage 
yourself (or with other proponents) for a while. Only then you can think 
of  far reaching decisions that touch all developers. I was ridiculed 
the same way during the GIT migration discussions, where everything 
would magically happen if we just migrated to GITlab, and the talk was 
similarly high level and tool-centric, borrowing a lot of enterprise pet 
projects and talking points. And here we are, 5 years down the line. No 
release. Stronger, with respect to releases, nothing _at all_  to show 
for it in all that time.

> --- On unstable trunk and the PPU rewrite ---
>
> This is the strongest point you raise, and I want to engage with
> it seriously. You are right that the proposal does not address
> trunk having been unstable for an extended period. In hindsight,
> the PPU rewrite is actually a good illustration of why the
> discipline the proposal describes matters: a large, unfinished
> feature should mature on its own branch and only land on main when
> it is genuinely ready. Merging it to main while it is still in
> flux is what caused the instability you describe.

The problem is that for larger features the stable/unstable question is 
not always as easy. Also when rotting in a MR/branch usually nothing 
happens.   As I said in the original post, these processes rely on 
oversimplification the complexities of merging revisions (e.g. relations 
between them), and judging sets of them good enough. The reality is not 
black/white but grey.

As for PPU rewrite, ask Michael why he merged it. My bet is that he will 
say this won't happen now any more, because he will ask Claude, or 
something along those lines.

> The Squash requirement makes a direct contribution here too. If
> every feature lands as a single atomic commit, reverting something
> that turns out to be problematic after the fact is a one-line git
> command rather than a surgery. 

As long as it is found out soon enough so that no revisions that come 
after builds on top of that of course. Dangerous for certain parts of 
the compiler and/or rewrites. Another such oversimplification.

> That does not change the need for
> people — but it does change how much damage a premature merge can
> cause.

I think it doesn't fundamentally change/solve anything. It just tries to 
shift around the blame. But in reality the pressure to merge of MR will 
only increase, with developers sometimes caving to the pressure, and the 
whole system breaks down.

> --- On complex, hard-to-merge branches ---
>
> The proposal asks MR authors to keep their branches rebased onto
> current main and to ensure CI is green before requesting a review.
> Hard-to-merge branches are then the author's problem to resolve,
> not the maintainer's. A maintainer who opens an MR and sees a
> failing pipeline or a rebase conflict simply does not act on it
> until the author resolves it — the triage label system makes that
> state visible without requiring anyone to personally chase it.

That assumes that a request review is immediately granted. But specially 
with difficult cases that can take time.

It also assumes that the test coverage is quite safe. With features 
often having crosstalk this is not always the case.

That is all about the compiler btw. For the rest branch complexity is 
more in revisions that touch a lot of files like e.g. the dotted unit 
stuff and the many replacements of string by ansistring etc.

> --- On the 130+ MRs ---
>
> I should have been clearer in the original email: those MRs do not
> all need to be merged. Many of them probably should not be. The
> triage pass is about giving each one a timely decision — Accept,
> Needs-Rebase, Needs-Review, or Closed-Stale — so the backlog
> stops growing silently. Closing stale or unsuitable MRs promptly
> is a perfectly valid outcome of triage.
>
The only relevance of MRs for the release process is that it can be a 
source of major features that are not releasable. In the case of major 
branches that can happen 1  to 1 1/2 years before the release.  Only a 
small fraction of the commits of a release cycle come from MRs.

If your focus of release is on improving MRs , you are looking at the 
wrong place.

> --- On tiered platforms ---
>
> I noticed your footnote about tiering platforms so that minor targets
> cannot block a final release. That is a genuinely good idea. it would
> be worth including that explicitly in any revised process, both to
> unblock the current situation and to prevent the same bottleneck in
> future cycles.

It was not much of a big deal, mostly it formalised an already implicit 
agreement. At best  it will spur the occasional minor platform 
maintainers to move a bit earlier, and not leave it to the last minute.

Still OS X/iOS is usually the biggest delay, and that is still tier 1.

> --- On walking a mile ---
>
> You are right that I have not managed an FPC release cycle, but
> I would be willing to give it a go if the team would have me.
> And here is the thing: if the process described in the proposal
> is followed, the Release Master does not need deep knowledge of
> the compiler or RTL internals. The role is about coordination,
> not implementation — knowing when to announce the Merge Window,
> when to cut the stable branch, when to trigger an RC build, and
> which MRs the subsystem maintainers have already labelled as
> ready to cherry-pick. 

It does require you to get a feel of the what the blocking issues are, 
to pre-emptively ask people to tackle them (or postpone).

> The domain experts are still the ones making the technical judgements; 
> the Release Master just keeps
> the train on schedule.

Usually the domain experts will say they have time not the next weekend, 
but the weekend after. Maybe.    Oops, it is related to a Tier 1 target;

Result: Schedule down the drain.

This is why I'm not a fan of overly complicated schedules and procedures 
for releases, in the end they break at the first hitch. Some minimal 
best effort ones are fine to give some guidance, but don't over 
formalise it. Deadlines are never hard in a volunteer project.

> If that role is not something the team is comfortable handing
> to someone outside the core group, I understand. There is still
> plenty I could help with: setting up the triage label workflow,
> improving the CI pipelines, or simply keeping the process
> documentation up to date. The intent throughout is to reduce
> friction for the people doing the real work, not to add to it. 

I would hesitate to give you the reins alone, but in combination with 
Michael that should be good enough. And I'll still do bulk cherry 
picking of non compiler revs. Nowhere it states it should be one person. 
And Pierre and Tomas are also still around.

But remember: baby steps at first. Do the work, and keep it short term. 
No pipe dreams of reorganising everything down to the last bit.

I would focus on creating lists of todos for (1) the fixes release or 
its RC2 (2) the next major branch. Do that in parallel, not leave the 
major branch till after 3.2.4 is done. Now.

Item one on the major branch todo would be " is the PPU troubles now 
really mostly done/stable?". What else is half-finished/not releasable 
on say a few months scale?

P.s.

yes, another PS. Since the Tier 1 bit landed, I'll mention another 
nugget that has been discussed about forever, or at least the whole SVN 
era.

Having (or going back to ) strict fixes releases. This opposed to the 
current fix+merge non compiler current state.

I don't care much about strict fixes releases, because they are near 
empty, and users have to wait a full cycle to see a fairly trivial 
packages or RTL fix. With major cycles of 5 years that is too long.

Note that means that I'm not interested in such minimal fixes releases, 
but If somebody wanted to manage that I have no objection.