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

[Martin Frb]

On 17/04/2026 16:06, Michael Van Canneyt via fpc-devel wrote:
>
>
> On Fri, 17 Apr 2026, Michael Van Canneyt via fpc-devel wrote:
>
>>>
>>> ----------
>>> 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.
>
> I was wondering why there is so much resistance to this idea, why people
> think it is cumbersome.
>
> There is a detail that is maybe unknown to erstwhile SVN users:
>
> When you look at a MR that was merged to devel, there is a link 
> 'Cherry pick'
> in the MR gitlab page. This will let you merge all commits of the MR to
> another branch (fixes or any other).
>
> This literally lets you merge a MR to another branch with some clicks. 
> No need for checkouts, merging manually, pushing etc.
>
> It can be done when a MR was just merged to devel, or can be done 
> later on.
>
> In case of conflicts, it's of course a little more work, but this has 
> always been so.
>
> But in the bulk of cases, it's just a couple of clicks and you're done.

Well, see my other mail...

But lets differentiate.

If I merged a contributed MR... And if I did that online... I have no 
issue to use the web to cherry pick it to fixes too.
(some MR I prefer to pull, and merge locally, and test (or add commits) 
before I push).

If I do my own commits (even If it was decided that every change, even 
single commits changes would go through a branch), then I would want to 
merge those branches locally.
Going to the web interface requires me to involve an additional tool, 
switching to my browser, needing my browser to go to another tab,  ... 
It may just be a few clicks. Its still less if I do it locally.

Also, given that I may have more than one branch in the works (that 
happens, even now, when I rebase everything on top of main), then 
switching tools adds a danger of having the wrong branch in the tool, 
and acting on the wrong branch.
That has happened locally too. But locally that is not an issue (well, 
its time lost, but all else recoverable). Locally I have the reflog, and 
can rewrite everything to what it should be.

--------------------
further doing my fixes-merges locally has advantages when I defer 
pushing them, wanting to wait if any issues are reported on main.

I then just have un-pushed commits on my local fixes branch, and rebase 
them when needed. But I have them all in one place, and ready to push.
I find that by miles more convenient than having to search gitlab for MR 
that
- are mine
- merged to main
- milestoned for fixes
- not yet in fixes

But on that last bit, I don't know, maybe gitlab has some bits to ease 
that (unlikely it will be as simple as my "git log fixes", but still.

I have to say, after all I am more of a git guy, than a gitlab guy.