Op 16-4-2026 om 00:06 schreef Graeme Geldenhuys via fpc-devel:
Show quoted text 12 lines
--- 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.
Show quoted text 10 lines
--- 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.
Show quoted text 9 lines
--- 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.
Show quoted text 9 lines
--- 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.
Show quoted text 7 lines
--- 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.
Show quoted text 11 lines
--- 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.
Show quoted text 6 lines
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 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.
