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

[Marco van de Voort]

Op 17-4-2026 om 14:42 schreef Martin Frb via fpc-devel:
>>
>> 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? 

I think Nikolay's comments about history are even more important. But 
yes, some relief of the insanity to let single commits bypass this 
mandate would be helpful.

And if not, then I think the onus should be on the people that request 
this. Since GIT (lab)is so advanced and flexible, we probably could 
engineer the workflow that way. So have the front main branch where 
simply every commit goes in, and then another branch "shadowmain" 
trailing it where the git overlords can squash and rearrange the input 
however they like?

Works for my case, but unfortunately not for Nikolay's.

> 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?

Currently even the main compiler developers afaik mostly commit 
directly., not via MR. I (almost?) never see a merge requests for a core 
developer in the list.

  Merge requests are (gut feeling) 50% by a handful of regular 3rd party 
committers and lazarus devels (the people that would rather quickly have 
gotten limited SVN access in the old days), and the other 50%, smaller 
requests by random 3rd party developers.

MRs are mostly a good thing, but as said I think the value of it is 
vastly overrated in the current situation, and there are dangers (people 
working very long, and then submitting huge requests for you to sort 
out).  Upping the requirements for merge requests will only increase the 
number of branches that are stalled because the submitter doesn't react 
or doesn't care. Invalidating the whole process.

> ----------
> 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).

That invalidates the gestation time in a public branch before merging to 
a stable branch. At least a couple weeks should be inserted.

But that is maybe not that different from how it goes now.  As long as 
there is a record of it (mergelogs or MR (main->fixes) list). The 
maintainers will let it linger the appropriate time. it is all less 
revolutionary than people pretend.