Re: new procedure with GitLab CI

[Jonas Hahnfeld]

Hi Valentin,

Am Freitag, den 29.05.2020, 19:03 +0200 schrieb 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.

I probably don't understand which problem you're articulating here. The
only thing that comes close is unhappiness about me maybe proposing
something at some point in the future?


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

With respect to needs_work, what would you propose to do? That's
exactly what we had in the past. Speaking at least for me, I don't want
to spend time on patches that don't even pass automated testing.
(except maybe for Proof-of-Concepts that are discussed on -devel)


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

From my perspective "checking" boils down to scrolling through the list
of MRs and see if a pipeline is running for one. Do you find this hard?

Jonas


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

signature.asc
Description: This is a digitally signed message part