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