Re: new procedure with GitLab CI

[Jonas Hahnfeld]

Am Samstag, den 06.06.2020, 08:57 +0100 schrieb Kevin Barry:
> The fast-forward rebase has two advantages that I can think of:
> - the git history is cleaner/easier to parse
> - it prevents the situation that sometimes arises where a couple of
>   patches - that pass testing independently, but will break when
>   combined - from making it into master (and breaking it)

This can be avoided by using merge trains which tests the simulated
merge(s) in order of their queue position:
https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
(We're not using this yet because it only makes sense with proper
merges, not with rebase + fast-forward.)


> If we move to merge commits our git history will mostly have a merge as
> every other log entry. It's a small loss, but a tolerable one in my
> opinion. I don't know how people feel about the second issue. The
> staging branch existed in the past to stop such breaks making it into
> master. Maybe it's OK since our source of truth is still on Savannah? I
> don't have strong opinions about it.

The mirroring is automatic, so everything that hits master on GitLab is
pushed to Savannah within 1-5 minutes.


> Is it a crazy idea to consider some automatic way of doing the rebase +
> merge on all branches in Patch::push state? I believe Gitlab allows for
> scheduled pipeline execution. (I'm just throwing the idea out there.)

I also mentioned the idea of a custom queue implementation initially.
However, I'd go a slightly different way:
 - Have a Patch::merging label that the author can assign *after* the
patch was in Patch::push.
 - Use some form of automation (webhook, cron?) that picks the "next"
merge request with Patch::merging and issues API calls to rebase and
merge.

The tricky part is the automation which needs a very robust design: It
must neither miss when to act nor act if there's a merge running that
it maybe didn't trigger itself. If somebody wants to do a prototype
implementation, I'm willing to give feedback and maybe help getting it
to the finish-line. For now, I personally prefer going back to "real"
development on LilyPond. I think there's a lot more to be done with
higher benefit.

Jonas

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