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

[Marco van de Voort]

Op 17-4-2026 om 11:57 schreef Michael Van Canneyt:
>
> It does: By better structuring - for example forcing the use of a MR -
> we can assign a milestone when accepting MR's and we'll have an exact
> list of MRs to go to fixes as well as devel.
>
/So much/ administrative overhead. And then we still have to find out if 
that concept works at all in the FPC context.

I would be against that.

> Merging to devel and/or fixes branch is then much easier: it already 
> groups commits that belong together.

Only the ones from that feature. But the next series of commits might 
built on this, creating dependencies again.

We used such philosophy in a previous job. No merge requests, but with a 
ticketing system were the sourcesafe and  later SVN revs were 
annotated. Of course merging and the like were not single mouse clicks, 
but the principles were the same.

But  this worked because nearly all work was daily maintenance of 
business rules and minor improvements/enhancement in an enormous 
mountain of business code.   This was enabled by the fact that most 
developers had their own specialism, and mutation rate of the shared 
core was very low, and even then not very intense. Features rarely 
touched each other, and if it did they were usually from the same 
developer.

Then you get indeed a kind of perfect independent set of features that 
you can mix and mash, but I can't imagine to see this fly for the 
compiler, not even for most of the rest.  Just see the constant 
restructuring that is going on (Nikolay's msg of today).

And the non compiler situation  is not that big a problem. I mostly do 
the merging on the side when I'l monitoring some remote sites.

> We can of course discuss "good practices" till doomsday come, but 
> unless we try
> something else we'll never know whether it works.
>
Well, maybe we shouldn't try then directly on the top level. Find some 
subsystem that you manage (pas2js, fcl-web or something like it) and 
accept only merge requests, and see how it goes for a major cycle.

No big bang scenarios as we had for the gitlab migration please, we have 
all seen what that leads to.