On 5/27/20, Jonas Hahnfeld <hah...@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.
