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

[Michael Van Canneyt]

On Sun, 19 Apr 2026, Martin Frb via fpc-devel wrote:

> On 19/04/2026 19:18, Michael Van Canneyt via fpc-devel wrote:
>>>> If there is, most of the time user needs to take action.
>>>> It's very rare that I must do it.
>>>
>>> For the current low amount of MR, indeed its rare.
>>>
>>> But if you scale up the amount of MR by making all team commits go 
>>> that way, and therefore also touch a wider range of code => then it 
>>> will happen more often.
>>
>> Why would that happen ?
> I gave an example, more simultaneous branches on a small amount of work 
> (since team members probably have "areas" on which they do concentrate 
> their work, and if the frequency of parallel commits/branches in a small 
> area goes up, then that is a risk factor for conflicts.
>
> This is based, on the branches existing for some time before merge. See 
> next part of reply.
>
>>
>> The member pushing the MR can merge it as soon as he created it.
> If it is merged immediately, then why do a merge request?
>
> If I have a commit (a commit of my own), that I just did myself (and I 
> did locally on my machine, as most people do for their own commits....
> And if I want that commit to be merged/cherry picked ...
> => why do I need to go via gitlab (as tool), if I locally already using 
> git, which can do the merge immediately? with no extra effort? Actually, 
> possible with even less work?
>
> What is the gain by going via MR @ gitlab?
>
> I thought your argument was to use the MR to track outstanding cherry 
> picks? But If they are already done, then they need no tracking 
> (tracking for future picking them)?

The logging and grouping. The CI/CD, and see below.


>> The point of the MR is to have a record of grouped commits that can 
>> easily
>> be flagged and merged later on.
>
> You just said "the MR can be merged as soon as it is created"

Yes. flagged is the key word.

>
>
> --------------------------------------
>>>
>>> Then we were talking about 2 diff things. I was under the impression 
>>> this was all still about the "every commit by every team member 
>>> should go via an MR".
>>
>> It is. See below, integrator role.
>>
>>>> Given the amount of work I do on MRs, if I can flag and later or 
>>>> immediatly merge MRs to a fixes branch, it would be a huge time saver.
>>>>
>>>> So if the team would also use MR's and just flag them 'fit for fixes'
>>>> then that should normally  result in more regular releases for the 
>>>> users.
>>>
>>> Is that you volunteering to look after the flagged commits?
>>
>> yes, obviously. The role is usually called an integrator.
> Ok, well, in that case I say, if you volunteer to do the work you have a 
> right to say in which way you want the "notification for outstanding 
> work" to be done.
>
> How much of a "pre-decision" lays by the committer?
> I.e., if the committer commits a new feature, they know that wont be 
> taken into fixes => so in that case they would NOT need a branch, and 
> NOT create an MR?

Theoretically, yes. 
But then the day of the release comes and suddenly 
'oh, can we please have these commits too?'

-> not an issue if there was a MR.

>From experience, after some time you stop thinking about doing a MR or not, 
you just do it. As I wrote to Marco, I do more than 7 MRs a week at work.

I feel in no way hampered by it:

I set to auto-merge, the CI/CD kicks in - takes 20+ minutes, and it's
merged.

> So the proposal you make would then be:
> - if anyone commits something that may (as in maybe) go to fixes
> - they commit into a branch.
> - they merge the branch into main, by any means they like (probably 
> except fast forward)
> - they create an MR (that can actually be an MR to fixes branch)
> => they are done.
>
> You will then deal with the MR.
>
> The MR replaces (or introduces) a means of "writing down" all/any 
> commits that may (maybe) go to fixes?

Yes.

>
> I think there is a selling point for that.
> (of course you have to still sell it to your team mates, rather than to 
> me / but if I was team, I would buy in)
>
> Might need some workflows for everyone, such as, if someone forgot to 
> create a branch => they then can use rebase to extract the commits into 
> a branch (creates a copy).
> (actually haven’t tested how clever gitlab is => if one creates a branch 
> at any point in main (then that point is the "fork point"), one could 
> then fast forward the branch. There would be no 2nd line of commits. No 
> visible branch point. But the fork point exists (I think it is taken 
> from the reflog, but I need to check). If one pushes before and after 
> the FF, then gitlab should have that fork point too.... Curious if such 
> a branch works for an MR.)
>
>
>>
>> We do this integration today, manually. It's clearly not working.
> Matches my observations (though I can't fully judge the reasons).
> But since your proposal includes your manpower, I would expect it to be 
> a true improvement)

That is what I am hoping.

>> By doing what I propose, the role of the integrator becomes much easier.
> That depends on the integrator, but in this case: Yes.

Yay, I managed to convince someone!

[Michael goes off to have a beer and celebrate]

Michael.