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

[Martin Frb]

On 17/04/2026 16:30, Michael Van Canneyt via fpc-devel wrote:
>
>
> On Fri, 17 Apr 2026, Martin Frb via fpc-devel wrote:
>
>>>
>>> But in the bulk of cases, it's just a couple of clicks and you're done.
>>
>> Well, see my other mail...
>
>
> We can of course all stick desperately to the old ways. I myself will 
> have to change my ways, I rarely make branches today.

My mail wasn't really about "not wanting to use branches" => I do that a 
lot, at least locally.

If I was affected (if I were working on fpc), then I would have to say:
- I prefer a largely linear commit history. My personal preference (but 
open wide to adaption) is to have
    3rd party in a branch
    team-commits mainly linear, but down to every team members preference.
   => in either case, as long as branches are rebased before merging 
(none-FF merges) then that is linear enough.

I do make a difference between
- git (and all that git allows us to do)
- GitLab
The latter is less important to me. It's a means to enable git.

Also, the conclusion of "sticking to the old way" just because I see one 
of a thousand possible new ways as maybe not that great => that 
conclusion seems a bit much...

-----------------------
For the rest, I don't know the full current way. I don't know the 
preferences of everyone in the the team....

IMHO the first is to decide (or establish, if the current is good) the 
flow. (And maybe you have that, and I - as outsider - miss that).
The tools can then be found to match the flow.

Of course proposed flows can be based on available tools => that makes 
sense. But at the same times, flows can be proposed to see if the 
tooling exists.

About the flow.

1) There are 2 type of commits that need merging/cherry picking to fixes
a) those that carry fixes or changes that in their own warrant the pick.
b) those that are needed to enable the above (dependencies / former 
changes that the "a" commits are based on)
=> the 2nd "b" group can be mostly ignored, as decisions on it are 
dictated by "a"

2) When (and by whom) are the decisions made what is a "a" commit (not 
the merging / the decision).
If the merging is later, then tooling is needed to record the decision 
(can be done)

3) When are the merges/pick done, and by whom. Are they required to be 
done in particular order?

4) any "after work" e.g. tests?


I would sort of except that "2" is done ASAP. In most cases (except 
where fixes are an unknown side effect) that would be at the time of 
pushing the commit (and by the person pushing it).

"3" There are arguments for either ASAP (more testing in fixes) or 
after-some-time (waiting for feedback from usage in main branch first).

-----------------------

The other big question (that is always forgotten in those discussion). 
Who? Who does it.

My opinion: Everyone. Everyone takes care that their own commits (if 
applicable "1a") are picked.
Unless, some one volunteered.

And actually that "everyone" works fairly well for Lazarus, IMHO.
With the addition, that for the few that aren't comfortable, their are 
others who help them. (based on just publishing the sha1 that should be 
done)


-----------------------
If the answer to "3" => "When" is asap, then everything that should go 
into fixes, is picked at the very moment that its is decided that it 
should. No need to tag it in any way as "needs to be picked".

If the answer is later, then you need a way to tag that.
Using MR is not the only way to do that.