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