Hello everyone, A few weeks ago I raised concerns about the 130+ open merge requests sitting unactioned in the GitLab instance. That thread drew a lot of responses, and it was clear the frustration is widely shared. What it did not produce was a concrete path forward.
Rather than continue that debate in the abstract, I spent some time studying how the Linux Kernel project manages its release process and what lessons might transfer to FPC. The result is a formal proposal, which I am sharing here for community review and comment. https://gitlab.com/-/snippets/5980608 --- What the proposal covers --- The central idea is a "Release Train" model: releases depart on a fixed schedule regardless of which features are ready, removing the "just one more thing" pressure that has kept us in freeze. The document covers: * A branching architecture with a clear separation between active development (main) and stabilisation (stable-X.Y). * A defined release cadence: Merge Window → Feature Freeze → RC Cycle → Release, with explicit durations for each phase. * A structured approach to the MR backlog using four triage labels (Accept, Needs-Rebase, Needs-Review, Closed-Stale), so we can work through it systematically before the first train departs. * Role-based Git command references for Contributors, Subsystem Maintainers, and the Release Master — covering everything from a simple bug fix to cutting the stable branch, tagging RCs, shipping a final release, and issuing hotfixes. * Automation for the fpc/build repository: when fpcsrc is tagged with a release or RC tag, a GitLab CI pipeline automatically pins the submodule pointers in fpc/build and applies the same tag there, eliminating the manual submodule update step. --- Immediate next steps proposed --- 1. Ship v3.2.4. It is already in freeze. Tagging it demonstrates the project is active and gives the community something concrete to point to while the new process is being adopted. 2. Designate roles: one Release Master, and at least one Subsystem Maintainer per area (Compiler, RTL, FCL, Packages). 3. Create the GitLab labels and run a triage pass over the open MR backlog. 4. Open the first official Merge Window for v3.4 immediately after v3.2.4 ships. --- A note on scope --- This proposal is not a criticism of the work anyone has put in. FPC is a remarkable project and the people maintaining it do so in their own time. The goal here is simply to reduce the administrative friction that currently makes releasing feel harder than it should be, so that the team's energy goes into code rather than process. I am aware that some of these ideas may not fit how the core team prefers to work. That is exactly why I am posting this as an RFC rather than a pull request. All feedback is welcome — including disagreement. Regards, - Graeme - _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
