Am Freitag, den 05.06.2020, 11:00 +0200 schrieb Valentin Villenave: > On 6/4/20, Jean Abou Samra <j...@abou-samra.fr> wrote: > > Actually, I had anticipated a long thread full of reactionson bothof the > > above options, but not such a silence. Anyone? (I won't feel offended if > > you find my proposal dumb!) > > Well, you have to account for the fatigue :-) > > I’m not knowledgeable enough to discuss the benefits and downsides of > merge commits vs fast-foward rebase, so I’ll leave it to others. But > I think you make a valid point in that our current linear > mandatory-rebase strategy is cumbersome, heavy on the CI pipelines and > generating a lot of noise.
I would like to comment on the last two points: * "heavy on the CI pipelines": The number of pipelines wouldn't change with merge commits. We still get one pipeline per push and we would want to get testing before a set of changes hits master. This is the same as we have right now. * "generating a lot of noise": The only "noise" is the rebase operation before merging. Everything else will stay the same: review comments, discussion, notifications about pushes, etc. NB: I don't see a need to rebase during review. If you chose to do it anyway, the same "noise" applies after switching to merge commits. The only advantage of merge commits that I agree with is GitLab's ability to queue merges and perform them automatically. That may qualify as less "cumbersome", but lowering the expectation that every merge request in Patch::push must be merged on the same day will get us the same result, without any change. > That being said, that’s only one of the three issues I raised in my > latest message (the other two being: how we’ll be handling Issue pages > from now on, and how patch reviewing can be made a bit more lenient > and smoother). Please see my replies from last Saturday which went unanswered AFAICT. Jonas > Jonas has started updating the CG, but that’s bound to reach a > roadblock if the underlying policies are not discussed and agreed upon > first. > > Cheers, > -- V.
signature.asc
Description: This is a digitally signed message part
