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

[Tomas Hajny]

On 2026-04-15 15:18, Graeme Geldenhuys via fpc-devel wrote:


Hi Graeme,

First of all - I understand that you try to move things forward and I 
appreciate your interest. In addition, I understand that you prefer 
start working on something than participating in potentially endless 
discussions. However, I believe that you should read at least some parts 
of that discussion. One of those parts is the question (very correctly 
raised by Marco!) how does having a fixed schedule ensure that the fixed 
releases contain considerable advances against each other while still 
ensuring reasonable quality / stability for patch releases. Please, see 
below for other two comments.

Regarding the number of merge requests - have you tried comparing the 
amount of changes waiting in the merge requests to the amount of changes 
pushed to the repository within the last 5 years? I didn't try to 
compare it myself, thus I don't know the answer, but I believe that such 
a comparison might be beneficial in order to find out whether the 
waiting merge requests (some of them probably useful, some other 
possibly bad and not appropriate for merging in any case) are 
substantial part of the problem, or whether there are other possibly 
much more important obstacles.


> 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.
  .
  .
>   * 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.

Please, read the discussion (especially our communication with Martin 
F.) to get better understanding why this particular part doesn't fit the 
needs. I don't say that nothing might ever change in this area compared 
to the current state, but please note that cross-building is _not_ 
applicable for all FPC supported targets and thus building for all 
targets cannot be tested / checked by a single person or anything like 
that - which is why testing the release build against once created tag 
is not enough.


  .
  .
>   2. Designate roles: one Release Master, and at least one
>      Subsystem Maintainer per area (Compiler, RTL, FCL, Packages).
  .
  .

What do you mean by the word "designate" here - do you have particular 
candidates in mind? Do you volunteer for one of these roles (which one)? 
Don't you miss target maintainers in your picture (see my comment above 
in this context)?

Tomas