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

[Michael Van Canneyt]

On Fri, 17 Apr 2026, Martin Frb via fpc-devel wrote:

> 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?

It's just a label to apply to a MR: backported.
You filter closed MRs (possibly 'milestone) with not backported -> you have your list.

> 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?

git branch x
...work...
git commit 
git push

ctrl-click link which gitlab presents you(!)
click OK
click 'set-to-auto-merge'

Relax while gitlab works.

I doubt the 3 extra clicks will make the bulk of the work.

Running the testsuite asks several minutes, so plenty of time to prepare the MR. 
(Florian's own words, BTW :-))

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

-> hence the milestone. when you create the MR, you decide if it is
'merge-worthy' and add the milestone. Later on you have 99% of your list for
free.

Like I said: a little upfront work to make life easier down the road.

We use gitlab only for a small part what it offers. 
The only gain we have today over svn is:

- MR (easier for others to contribute)

- CI/CD (half useful, we have our own testsuite)

All I'm proposing is that we use it a little more what it is intended for.

Will it cover all cases ? No. No system ever will.

Will it make life easier? Yes.

Michael.