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

[mailinglists at geldenhuys.co.uk]

Hi Tomas,

Thank you for the response.

--- On fixed schedule vs. quality ---

I want to clarify what the fixed schedule actually controls in the
model: it governs *when the train departs*, not *what boards it*. The
Merge Window determines the content of any given release. If a feature
is not ready, it simply waits for the next train.

The reason I believe a fixed schedule still helps, even if some
releases are lighter than others, is that the alternative is
demonstrably not working. v3.2.4 has been "almost ready" for two
years. Waiting until a release feels "substantial enough" has no
natural stopping condition. A fixed departure time does.

That said, I think the cadence needs careful thought for a project
of FPC's size and contributor base. Looking at the volume of commits,
I believe 6-month or even 12-month cycle will be appropriate.
No need to chase a release every two weeks like the Linux kernel -
though that proves that a mammoth project has the ability to do that,
so FPC should in reality be a walk in the park.

--- On the MR count vs. commit activity ---

You make a fair empirical point, and I genuinely do not know the
answer either. It would be worth someone running that comparison
before we treat the MR backlog as the primary symptom.

What I would say is this: even if the 130+ MRs represent a small
fraction of total changes, the fact that contributors have submitted
work and received no signal for years has a cost that does not show
up in commit counts — it affects contributor retention and community
confidence.

The triage process in the proposal is not about merging
all 130; it is about giving every one of them a clear, timely
answer in either direction.

--- On the CI automation and cross-building ---

This is the strongest point you have raised, and I will be direct:
the proposal as written is maybe a bit thin on details here.

You are absolutely right that a green CI run on x86_64/Linux is not
a meaningful "release is ready" signal for a compiler that targets
DOS, Amiga, embedded ARM, and dozens of other platforms that cannot
be tested in a standard CI environment. The automation I described
for pinning submodule pointers in fpc/build is still valid as a
mechanical step. If the CI can cover where 80-90% of the FPC userbase
sit, that should be plenty good enough. The way lesser used platforms
will simply trail along.

A revision worth considering: rather than the tag being the sole
trigger, the RC cycle could include a lightweight sign-off checklist
— one entry per supported target — that target maintainers update
as they validate their platform. The final release tag would only
be applied once all _critical targets_ [the 80-90% of users] have
a green tick. GitLab supports this via a checklist in an issue or
MR description. This keeps the automation useful while acknowledging
the multi-target reality.

I would very much welcome input from you or anyone else, what a
workable sign-off mechanism would look like in practice, and what
is considered the Tier 1 platform (data backed info would be very
useful here).

--- On roles and volunteering ---

"Designate" was poorly chosen — it implies authority I do not have.
What I meant was: for the process to function, someone needs to
agree to own each area. I cannot assign that; the team has to.

You asked whether I volunteer, and which role. I am happy to take
on any of triage coordination, process documentation, CI pipeline
improvements or even try my hand at release manager. I
acknowledge that domain ownership of Compiler, RTL, and FCL has to
come from people with far deeper knowledge of the internals than
I have.

You are also right that "target maintainers" are absent from the
proposal. That is a real gap. The model needs a named person
responsible for each primary target, both for ongoing review and
for the RC sign-off I described above. I will update the proposal
to reflect this.

--- Summary ---

The proposal is a starting point, not a finished plan. The feedback
so far — yours, Marco's, and others' — is making it better. I will
revise the document to address the cross-building/sign-off gap and
add target maintainers as a defined role, then share an updated
version here for further review.

Thanks again for taking the time to engage with this.

Regards,
  - Graeme -