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

[Martin Frb]

On 17/04/2026 14:11, Michael Van Canneyt via fpc-devel wrote:
>
>
> On Fri, 17 Apr 2026, Marco van de Voort via fpc-devel wrote:
>
>>
>> Op 17-4-2026 om 11:57 schreef Michael Van Canneyt:
>>>
>>> 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.
>>>
>> /So much/ administrative overhead. And then we still have to find out 
>> if that concept works at all in the FPC context.
>
> There is no administrative overhead. I'mm not proposing to work with 
> epics,
> stories and whatnot.
>
> No: You create a branch, develop your thing, and push. That's it. 
> Press a button to merge.
>
> The difference with before: we have a good record that's easier to handle.

Maybe I am missing something, but this leaves a big part of Marco's 
concern standing.

1) It does not address anything that isn't in a branch. I would expect 
many bug fixes are one or 2 commits and aren't going via a separate 
branch (let alone an MR).
Then you still need a 2nd list to track "bug fix" commits?

2) If anything else needs to be merged, how much of that is today 
developed in a branch (and gets an MR)?
I.e. how much overhead for all of the FPC team to move any "potential 
merge" work into branches upfront, and create MR for those?

----------
But the core idea (if that does not already happen?):
    When a commit makes it into main, decide then and there if that 
commit may (maybe) go into any fixes branch. (does not cover any 
dependencies, just the commits that of their own accord want to be in 
fixes).

How to document that decision is 2ndary.