Re: new procedure with GitLab CI

[Valentin Villenave]

On 5/27/20, Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> No, "rebase" is currently manual (with "merge when pipeline succeeds"
> being automatic). This has been clearly communicated, sorry if you
> missed that.

Hey Jonas, hey everybody;
just so you know, I’m getting increasingly frustrated -- as you may
guess if you take a glance at the thread on
https://gitlab.com/lilypond/lilypond/-/merge_requests/95#note_351258804
-- with the GitLab process.
There *are* definite improvements over the previous arrangement
(although James may probably be in a better position than us to
appreciate this).  But here are my three pet peeves at the moment:

-- Issues & Labels.  Not that I’m particularly keen to revisit that
matter here; I’ve learned my lesson and stopped trying to intervene
and triage any Issues; it remains to be seen whether
    a) Milestones are a good fit to replace Fixed_2_xx_xx labels;
    b) we’re scrapping the process of a) marking as Status::Fixed, b)
waiting for the next GUB unstable release, then c) going through them
one by one (ideally by somebody else) and d) marking them as
Status::Verified.  I’m very much against ditching that; Jonas,
however, thinks that (IIUC -- please correct me if I’m wrong) as soon
as an issue is considered “Closed” within GitLab, its status is no
longer relevant.

-- The need to let the pipeline run every time an MR branch is
touched: rebasing (no matter how many commits behind one may be),
addressing a reviewer’s suggestion (no matter how minor), on penalty
of getting stuck in Patch::needs_work land and getting a distinct
chance of falling through the cracks.  I *am* very much in favor of
every patch/MR getting through the pipeline when it first gets posted
and at least once or twice before it gets merged; I just think that
during the reviewing process the pipeline *could* be put on hold for
minor changes while we’re getting stuff in shape.  (And *no*,
needs_work is not appropriate in that sort of situation.)

-- The merge window (every three days) is getting ridiculous.  Now
we’re all asked to check, re-check, double re-check, triple re-check
the pipeline list to hopefully get our branch rebased and merged at
some point; if we’re unfortunate enough to stumble onto another
merging process already engaged, there is nothing else to do but come
back an hour later, quite possibly only to discover that someone else
got in first.  I’m not blaming anyone for that, but surely there must
be a way of smoothing out that process, for example some sort of a
waiting list.  Maybe something as dumb as sending an email on -devel
or writing down our MR’s number on an Etherpad somewhere.

And, yes, I am grateful towards Jonas for everything he’s done and the
increased activity we’re seeing because of his work.  I’ve already
tried to talk things through off-list; now I think we need to talk
things through with others in the team.  Jonas, you may not know me
well enough to know how emotional I tend to get, and how easily I tend
to just give up and drop off the map (the difficult times I’m going
through IRL, as some of you guys may be, certainly don’t help); so
please, please don’t take this message as an attack, because it
certainly isn’t intended as one.  (If anything, this is me trying to
de-escalate a potentially tense situation; the words I’m using may not
be the most appropriate ones in that regard, but they’re the only ones
I have at hand so I apologize for that.)

Cheers,
-- V.