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

[mailinglists at geldenhuys.co.uk]

Hi Marco,

Thank you for the candid response. I would genuinely rather have
direct pushback than polite silence, so I appreciate it. Let me
respond to a few of your points as honestly as I can.

--- 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.

--- 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 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. That does not change the need for
people — but it does change how much damage a premature merge can
cause.

--- 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.

--- 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.

--- 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.

--- 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. The domain experts are still the ones
making the technical judgements; the Release Master just keeps
the train on schedule.

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.

Regards,
  - Graeme -