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