We have a self supporting cohort of RMs, voters, and contributors for branch-2 but not branch-1. I agree this is misaligned with the user centric focus if we define 'user' as someone using a version that has the stable pointer pointing to it. (smile)
If anything this thread is a plea from me to build a self supporting cohort of RMs, voters, and contributors for branch-1. It should not be as hard as it has been for myself, Francis, and I think Sean to get 1.x release votes to complete. There should be more contributions to test hygiene and compatibility concerns (when agreed upon) in branch-1. On Thu, May 9, 2019 at 5:42 PM Sergey Shelukhin <[email protected]> wrote: > That would be interesting given that in our experience prototyping on > branch-2.1, it is really not ready for production usage. > We fixed many bugs (mostly in the assignment; most either committed or PA > in JIRA, internally we run with all of those) and keep finding new critical > ones all the time (e.g. recently we started running into non-HDFS ProcWAL > corruption, not sure yet why, lost recent repro). > And we haven't even turned on region splitting yet ;) > > So 1.X line appears to be the only actually stable one right now. > > -----Original Message----- > From: Andrew Purtell <[email protected]> > Sent: Thursday, May 9, 2019 10:38 AM > To: dev <[email protected]> > Cc: [email protected] > Subject: Re: I'm about to give up on RMing > > Also, it is my observation that we are really only seeing difficulty > attracting votes when RMs offer a 1.x release candidate. Maybe this implies > the entire branch-1 forest should EOL. This will strand major users still > on 1.x but it appears to be the consensus will of the community, if you > interpret a lack of voting interest in that way. > > > On Thu, May 9, 2019 at 10:32 AM Andrew Purtell <[email protected]> > wrote: > > > Sure I will concede treating -1s as vetos is a contributing factor, > > but I think this is just a nod to reality. We have a hard enough time > > attracting votes on a candidate as it is. When a -1 is cast, maybe I > > am insufficiently optimistic, but I strongly suspect we won't get enough > +1s to overcome it. > > I think that is a realistic outlook. When someone comes to the thread > > and sees a -1, will they bother? The -1 becomes a fait accompli, in my > > estimation, so I treat it as a de facto veto. Perhaps this isn't the > > right thing to be doing after all. Let me try your suggestion. > > Currently there is a vote in progress on 1.4.10RC0 with one -1 vote > > and no other votes, with a closing date of tomorrow. It doesn't look > > promising I have to say but let's let it continue. > > > > I would like to continue with RM duties. I enjoy it for the most part. > > It is the voting that really kind of sucks now. It's hard to attract > voters. > > They make pronouncements without offering any volunteer effort in return. > > That has become frustrating. > > > > > > On Thu, May 9, 2019 at 10:26 AM Sean Busbey <[email protected]> wrote: > > > >> -1s on a release aren't a veto unless the RM treats them that way. > >> Granted, given our current rate of votes they are very hard to > >> overcome. I'm painfully aware of the time that goes into putting up > >> an RC, and I don't think you should continue handling -1s as vetos. > >> > >> As a voter on RCs I try very hard to reflect on wether or not > >> something can be addressed in future releases or via a release note. > >> I usually don't preemptively file a JIRA unless there's a clear > >> problem and solution to be had. > >> > >> Personally, as a RM I try to gauge wether or not to abort an RC > >> depending on the specifics of the -1 votes cast. There's very little > >> chance I would sink an RC for a test I can't reproduce. Including a > >> release note is probably enough. I do tend to be more sympathetic to > >> compatibility concerns. I think the only way to get meaningful > >> assurance that the artifacts coming out of the project are what we as > >> a project support is to support folks voting according to the > >> standard they hold without requiring that any problems come with a > solution. > >> but that doesn't work if a single -1 can block a release. As you > >> mention, that just becomes a hot potato of work without a volunteer. > >> > >> You've been doing an outsized share of the RM work for a long time > >> Andrew. As someone else who's done some of that work, I can empathize > >> that it's a grind without much noticeable appreciation. I don't have > >> a good answer for what it takes to get us through that discussion. If > >> a break from dealing with release management duties would help you > >> stick around longer contributing in other ways, e.g. evaluating RCs > >> and voting or reviewing features, then please go for it. It will > >> definitely be painful for the project's release cadence, but a > >> regular cadence of releases should be the responsibility of the > >> entire PMC and not one or two individuals. > >> > >> In the specific case of 1.4/1.5 RCs, I haven't caught up on the > >> current status yet but I'm happy to take a look and break off a > >> discussion thread for whatever is currently blocking things. > >> > >> On Thu, May 9, 2019 at 11:41 AM Andrew Purtell > >> <[email protected]> > >> wrote: > >> > > >> > .. a code base to the RM role. I don't believe vetos for RCs for > >> > flaky tests should be considered valid reason to vote -1. I think > >> > we may be erring toward excessively maximal interpretation of > >> > compatibility guidelines in some cases. At any rate, where does the > >> > responsibility lie for fixing the issues? And do voters consider > >> > the personal cost to the > >> RM > >> > in terms of time and attention in rolling the RC when deciding to > >> > vote > >> -1? > >> > The -1 vote has a cost. It requires the RM to restart the RC. My > >> impression > >> > is this isn't a consideration. > >> > > >> > > >> > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell > >> > <[email protected] > >> > > >> > wrote: > >> > > >> > > /cc private@ > >> > > > >> > > I believe you are pushing your collective burden as a group of > >> committers > >> > > sharing responsiblity to > >> > > > >> > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell < > >> [email protected]> > >> > > wrote: > >> > > > >> > >> My experience with the last four RC attempts I have made has > >> > >> been > >> just a > >> > >> constant stream of vetos for flaky tests which I can't reproduce > >> > >> (at > >> least > >> > >> not with the usual 10 iterations of the suite) and possibly > >> > >> pedantic compatability report interpretations with no patches to > >> > >> help and in > >> some > >> > >> cases not even JIRAs filed to follow up on specifying the > complaint. > >> Life > >> > >> is too short to waste time and effort like this. > >> > >> > >> > >> > >> > > > >> > > -- > >> > > Best regards, > >> > > Andrew > >> > > > >> > > Words like orphans lost among the crosstalk, meaning torn from > >> > > truth's decrepit hands > >> > > - A23, Crosstalk > >> > > > >> > > >> > > >> > -- > >> > Best regards, > >> > Andrew > >> > > >> > Words like orphans lost among the crosstalk, meaning torn from > >> > truth's decrepit hands > >> > - A23, Crosstalk > >> > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
