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

[Martin Frb]

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.

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

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)

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


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

Using gitlab to accept MR is (mostly) fine. I.e. for those are small 
enough to just look at the diff and that is enough to review => I use 
the online "merge to main" button too.

I have not yet come to the point were I knew at that very point that I 
want to also pick it into fixes.
But if I knew, at that very time, then that cherry pick button would work.

In other scenarios, other means may be faster (not in all cases, in some 
cases).

---------------------------
However that is away from the original issue of how to improve tracking 
what goes into fixes -> 3rd party MR are only a fraction of that.



>
> 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?
Or you expecting everyone to then search there flagged MR and deal with 
them themself?

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

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.
Done.
No extra steps.
Just the cherry pick.


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

I am neither comparing with SVN means (I didn't even touch branches back 
then), no do I advertise to stick with those means.

Git (and the surrounding tools) offers plenty of ways => each task can 
be solved in many of them.

There are people who say that all commits must first be in a feature 
branch (and then go over various means into various other branches...) 
=> we don't do that. Even so some people will tell us that not only is 
this the best way, its is supposedly the only way that works at all. I 
disagree. Strongly. Very strongly.


------------------------
And even if MR would be a good way (which I am not convinced because I 
think other ways are better.
At least for commits by the team, which often are either
- single commits
- single commits with dependencies (that wouldn't be identified by the 
MR either)

For starters, mix them with regular MR in the MR list on gitlab => you 
get a mixed list that you need to sort and search
- MR by 3rd party only for main
- MR by 3rd party merged to main, waiting for cherry pick to fixes
- MR by team against the fixes branch

That adds work, were we should seek to reduce it.

So again, unless you did just volunteer to then do all the cherry picks 
=> then I am pretty sure they will just sit on gitlab, and nothing will 
happen with them.
- You may call it pessimism, I call it experience ;)


For the few cases where entire branches wont to be picked to fixes (e.g. 
3rd party MR) / I don't know how often that happen with "team origin" => 
that can maybe be considered. (not my call, but..>)
Though it might lead to splitting the list of "to be picked commits"

=> for all others, I would either
- pick the directly into fixes
- pick them locally into fixes, push when they had some testing in main
- pick them to a "pre fixes" : same as locally, just push, but as "trial 
and error fixes branch" from which they then later get picked into real 
fixes

the last one also works for "branches that were merged".