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

[Michael Van Canneyt]

On Sat, 18 Apr 2026, Martin Frb via fpc-devel wrote:

> On 18/04/2026 12:01, Michael Van Canneyt via fpc-devel wrote:
>>
>> You were conveniently ignoring this part in your reply. You have to 
>> handle the user's MRs in gitlab.
>
> I thought the part where I wrote
>> 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. 
>
> I.e. When/If I do it as part of this handling.
> That is not always the case. (and the other obstructions)
>
> So, no: I did not ignore that.

I didn't make the link, I stand corrected on that account.

>>
>> Which is exactly what I am doing:
>>
>> Merge Requests Grouped by User:
>
> This is probably mixing 2 things up now (I still reply just in one bit)
> - merging into main (which was *not* the topic / and which I do to, 
> except cases that I described separately)
> - using the cherry-pick button.
>
>
> That list is
> - merging them into main

Merging into main.

> - merging them, and cherry picking them into fixes **at the same time**
> - merging them, and cherry picking them into fixes **at a later time**
> ?
>
> And:
> - How big where they.
> - How much review was needed

Depends on the MR. Some bigger, some smaller.

> - How much code in places **not adjacent to the diff** needed to be 
> looked up for the review
> - How many of them needed conflict resolution
>
>
> On the last point: It may be that for you conflict resolution works fine 
> in the gitlab interface.
> For me, that is - half the time - not the case.

We must have very different users.

I don't think even 3% neeed conflict resolution.

If there is, most of the time user needs to take action.
It's very rare that I must do it.

> I do regularly open conflicts (with the >>>> markers) in the IDE, and 
> resolve them there. It's just for me personally that works better in 
> those cases.

I never use gitlab to resolve conflicts. 
I do the same as you, but see above.

> ----------------------
> I am missing your response to the following.
> Which is
> - *NOT* about MR from 3rd party

It is about MR from 3rd party.

My point was that since we have gitlab, the merging of user contributions
goes way faster than the SVN+Mantis procedure, where we had to download and 
apply patches manually. Anyone denying that is denying the light of the sun.

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.

Because that is what it is all about: 
getting out more releases for the user.

Gitlab (or github) helps in that, but you must use it for what it was meant.

The older SVN public sites were obliterated by github/gitlab. 
That was definitely not because it the latter were more difficult to use.

Michael.