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
