[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 15:18, Michael Van Canneyt via fpc-devel wrote:
>>
>>
>> On Sat, 18 Apr 2026, Martin Frb via fpc-devel wrote:
>>
>>> 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.
>
> Misunderstanding....
>
> Half of the time that need conflict resolution => Of those times that 
> need it, take half.

Well, since we don't do conflict resolution in gitlab, the point is moot.


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

The member pushing the MR can merge it as soon as he created it.

The point of the MR is to have a record of grouped commits that can easily
be flagged and merged later on.

> Quite possible even between commits of the same person. => I have plenty 
> of conflicts between my own branches. (because by nature they work on 
> the same range of code / so if I do more than one thing at a time, then 
> conflicts are natural)

Makes no difference then. You'll have work either way.

>>> 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.
> Hope my new reply explains it better.

Considerably, yes.

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

We do this integration today, manually. It's clearly not working.

By doing what I propose, the role of the integrator becomes much easier.

> Or you expecting everyone to then search there flagged MR and deal with 
> them themself?

That would be utterly pointless.

> And, if it is:   everyone taking care of their own MR
> => then why doing an MR at all, why not just instantly cherry picking?

Indeed.

> That what we (Lazarus) currently do (with slight extra for the few not 
> yet that comfy with git) => If someone commits something, and its fixes 
> worthy they cherry pick it.

That's why IMO the MR is better. if you have 10+ commits, you do it in one fell
swoop with the MR, and (a benefit IMO) it can be done by someone else 
(the integrator). All the developer needs to do is merge and flag the MR.

An additional advantage of MR is also that we can run CI/CD once before merge; 
doing CI/CD for every push is most likely not going to work any more once 
we make the CI/CD work for all platforms. The allowed compute time is not
infinite, and as soon as a new push is done, an existing pipeline is
aborted, making error detection much harder. the gitlab mails which I
receive often indicate the wrong commit because of this.

Are there some extra steps for the dev ? Yes, obviously.

But if it results in more frequent releases, then IMO that's worth it.

Michael.