-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
