Re: new procedure with GitLab CI

[Jonas Hahnfeld]

Am Freitag, den 05.06.2020, 11:00 +0200 schrieb Valentin Villenave:
> On 6/4/20, Jean Abou Samra <jean@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