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

[Michael Van Canneyt]

On Thu, 16 Apr 2026, Marco van de Voort via fpc-devel wrote:

> Automating building and branching is all fine and dandy, but the problem 
> is to actually get content (read: merged revisions) in those branches, 
> and your proposals are awfully quiet about that. It sets a few schedules 
> and rules (that basically are an toothless appeal to developers "to 
> think about the releases and do the merges", but all developers could 
> have merged all their commits in the current situation already, so what 
> effectively changes).
>
> You are trying to fix a basic problem (no people actually doing 
> something) with lots of high level rules and infrastructure that is 
> copied from large scale projects that allows managers to track progress 
> of the grunts. IMHO it simply doesn't make sense in a FPC volunteer context.

It does: By better structuring - for example forcing the use of a MR -
we can assign a milestone when accepting MR's and we'll have an exact
list of MRs to go to fixes as well as devel.

Merging to devel and/or fixes branch is then much easier: 
it already groups commits that belong together.

By forcing a little more work upfront, we reduce the work later on, and we'll
not be stuck with a bazillion commits that no-one knows how to handle.

As I understand it, many people use the fixes_x branch, so it'll also be
tested a lot sooner.

We can of course discuss "good practices" till doomsday come, but unless we try
something else we'll never know whether it works.

Michael.