Re: new procedure with GitLab CI

[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)

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.

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.)

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.