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

[Marco van de Voort]

Op 18-4-2026 om 16:08 schreef Michael Van Canneyt via fpc-devel:
>
>>>
>>> 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.
>>
>> Still that is different than the proposal.
>
> It is not.
>
My point is your math doesn't add up even for the main list, and the 
whole release angle is even more far fetched.

Let's get back to releasing, how many of those merge requests have you 
merged to fixes?

>>> 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 maybe 50 of your MRs apply,
>
> Since I am the one doing the work, I think I'm better placed to judge:
> It will be more than 400, I assure you.
>
> I'll be mild: The day when you reached 200 merged MRs, we'll talk again.
> Maybe at that point you'll have enough experience with it to accurately
> judge the advantages it brings (or not).

That is /mild/ in your book? After having done 75% plus of all merging 
since FPC 2.0.4 ? Maybe 20000+ revisions or more?

And that is not just historic, just check the history of post 3.2.2 
revisions in the GIT era.   Compare that number to your 200 MRs.

> If you can overcome your prejudice, that is: instead of fighting the 
> tool,
> try embracing it. It will make your life easier, maybe even more fun.
>
Maybe, if you ever make a compelling case for it instead of trying to 
use every little tidbit to glorify your proposal and vilify the old 
procedures. That doesn't instigate trust.

But the core point is and remains: bulk merging to fixes is not the 
cause of release delays. Period.