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