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

[Martin Frb]

On 18/04/2026 11:05, Michael Van Canneyt via fpc-devel wrote:
>
>
> On Fri, 17 Apr 2026, Martin Frb via fpc-devel wrote:
>>
>> If it is just the MR click on "cherry pick this" => then I wouldn't 
>> call that "tooling you get with Gitlab" => for that Gitlab is just a 
>> client, like any other git client. And you can do that with any other 
>> git client.
>
> The difference is that in gitlab it takes all the commits from the MR.
If the MR is merged, I have a branch with all the commits. Most local 
GUI clients will make it very easy to select that for picking => so 
there is no real difference in that.
I stand by: That button in gitlab is no better tooling than any other 
(halfway decent) GUI client. (GUI, since the web is GUI too)

> on the command-line, you need to specify all commits yourself.
>
> Secondly, when you are handling the MR (which you must do anyway if it is
> a 3rd party MR), you are already in gitlab, so it is right there under 
> your nose. It's literally a click away.
>
> You can of course go back to the command line and do everything 
> manually there
> after merging the MR if you are so inclined.

1) "not related to cherry pick button"
Yes, an MR has advantages over a PR (the original Pull request). Well in 
some cases.

A small MR is easy to handle on the web.

But if the changes a big, I personally find it impossible to review on 
the web. I need to be able to look up other (existing) code. I need the 
code (the proposed new code) in the IDE, to be able to use todetools, 
follow it around, proper review it.
Trying to do that online does not work for me, **IF** the MR is 
sufficiently big.


2) --- the actual "cherry pick this MR" ---

That is fine online (and I said that before!).  But I also said: only if 
I do it immediately.

If I merge the request now, and in a month decide I want to cherry pick 
it => having to find it again online is more work than finding the 
branch in my local GUI client.
Yet it would not matter, since the diff is really slim.

Of course: If I
- merge now
- want to keep some form of list (bookmark) to review merging in a month
=> then tagging the MR is ONE way (one of many).


If I use the MR as bookmark, then using the "cherry pick" button is fine 
**IF** and only if there are no conflicts.
If it does have a conflict => I *sometimes* find it easier to resolve 
conflicts in the IDE that in any "merge/conflict" viewer.
"sometimes" => not always, but often enough.
So if there is a conflict, it may tremendously speed up the process (for 
me) if I already have it local. Of course, if I have the MR already 
open, I don't mind trying to click the button, and abort if it conflicts.

But using the MR as bookmark => well if there is a volunteer who will 
process all that bookmarks then fine.
If I have to use the (rather limited) search (including advance gitlab 
search) to find "just the bookmarks that I handle" then tagging MR is at 
best an average solution. (see the "amount of MR" below)


----------

Again just adding my experiences as a means to broaden the view. Sure it 
can be solved... As for if and to which extend which solution is wanted, 
that isn't my decision.

----------

Also, I must say, if I understand that correct, and if every change 
(including every single commit fix) goes through an MR, then you have 
hundreds (thousands?) of MR => Essentially the entire "git history" 
duplicated into MR => not something that I find reasonable.

Albeit, it would mean that fpc team members don't have to create the MR 
=> you can have a bot that creates an MR for every commit pushed.