On Thu, 16 Apr 2026, Marco van de Voort via fpc-devel wrote:
Automating building and branching is all fine and dandy, but the problem
is to actually get content (read: merged revisions) in those branches,
and your proposals are awfully quiet about that. It sets a few schedules
and rules (that basically are an toothless appeal to developers "to
think about the releases and do the merges", but all developers could
have merged all their commits in the current situation already, so what
effectively changes).
You are trying to fix a basic problem (no people actually doing
something) with lots of high level rules and infrastructure that is
copied from large scale projects that allows managers to track progress
of the grunts. IMHO it simply doesn't make sense in a FPC volunteer context.
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.
Merging to devel and/or fixes branch is then much easier:
it already groups commits that belong together.
By forcing a little more work upfront, we reduce the work later on, and we'll
not be stuck with a bazillion commits that no-one knows how to handle.
As I understand it, many people use the fixes_x branch, so it'll also be
tested a lot sooner.
We can of course discuss "good practices" till doomsday come, but unless we try
something else we'll never know whether it works.
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
