On 17/04/2026 14:11, Michael Van Canneyt via fpc-devel wrote:
On Fri, 17 Apr 2026, Marco van de Voort via fpc-devel wrote:
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.
There is no administrative overhead. I'mm not proposing to work with
epics,
stories and whatnot.
No: You create a branch, develop your thing, and push. That's it.
Press a button to merge.
The difference with before: we have a good record that's easier to handle.
Maybe I am missing something, but this leaves a big part of Marco's
concern standing.
1) It does not address anything that isn't in a branch. I would expect
many bug fixes are one or 2 commits and aren't going via a separate
branch (let alone an MR).
Then you still need a 2nd list to track "bug fix" commits?
2) If anything else needs to be merged, how much of that is today
developed in a branch (and gets an MR)?
I.e. how much overhead for all of the FPC team to move any "potential
merge" work into branches upfront, and create MR for those?
----------
But the core idea (if that does not already happen?):
When a commit makes it into main, decide then and there if that
commit may (maybe) go into any fixes branch. (does not cover any
dependencies, just the commits that of their own accord want to be in
fixes).
How to document that decision is 2ndary.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
