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.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
