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

[Martin Frb]

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


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

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?

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)


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