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

[mailinglists at geldenhuys.co.uk]

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 -