Personally when available I spent more time in branch-1 release voting than branch-2 since I think branch-1 is still the stable pointer, also the main usage in production. For the same reason I'm more cautious to give a +1 for branch-1. For me a -1 is not a veto but something noticeable, while I also agree that if I saw a -1 I will wait for RM's explanation or the next RC to cut my own vote, so I myself will change to use +0 in future.
I share the same observation that branch-1 releases are hard to attract votes. Probably this reflects that more users (at least PMCs) are waiting for a stable branch-2 release for upgrading rather than a new branch-1 one? If this is the case, then IMHO we should move our stable pointer to branch-2 and EOL branch-1 asap. Or if users are still expecting branch-1 releases but PMC focus more on branch-2, we should figure out a way to resolve the conflict. I'd like to emphasize that I think you're a great RM Andrew (and I could recall the good memories using 0.98 series in production). And I could feel your frustration and my apology if my -1 on 1.5.0 RC is part of the reason (although not on purpose). Best Regards, Yu On Fri, 10 May 2019 at 08:59, Andrew Purtell <[email protected]> wrote: > > In that regard I think we should be easier on newcomers. Old timers > should know better and follow up with jiras. > > This is a fair point. > > I would say anyone should feel free to raise a question in the vote thread, > or file a JIRA and mention it. I can only speak for myself but questions or > concerns raised during a vote are not what is frustrating about RMing at > this time. It's great to see the engagement. > > > On Thu, May 9, 2019 at 5:49 PM Artem Ervits <[email protected]> wrote: > > > Andrew, I can only imagine how hard it is to be an RM, it takes me hours > to > > review a release let alone roll one. With so many RCs for each branch, > it's > > hard to focus on which branch to target and like you said volunteer time > is > > expensive. Sometimes for new contributors it is uncertain whether the > > observed behavior is intentional or something to be concerned with. I > like > > to point those issues out on a vote and gauge the RM and other voters' > > opinion whether it calls for jira. In that regard I think we should be > > easier on newcomers. Old timers should know better and follow up with > > jiras. Im guilty of calling out certain nits, case in point > > hbase-connectors vote. [1] Luckily feedback loop was quick and we were > able > > to get subsequent issues fixed as part of jiras. It goes back to being > good > > citizen of the community, I'm happy to do reviews but maybe what we > should > > also do for each specific release, call out the issues to test in the > vote > > thread. > > > > That said, question I had for releases below 2.1, do we want to publish > > client binaries [2] or is it something we want to do going forward? > > > > [1] > > > > > https://lists.apache.org/thread.html/2e94a8da7df937e9adf7dc12212ade2eb24f920bb293430e439dde5c@ > > <dev.hbase.apache.org> > > > > [2] > > https://issues.apache.org/jira/plugins/servlet/mobile#issue/HBASE-19735 > > > > On Thu, May 9, 2019, 1:42 PM Andrew Purtell <[email protected]> wrote: > > > > > Yes, I am already using that phrasing, because it is very difficult to > > get > > > voting interest in any 1.x release candidate. See my other response in > > this > > > regard. As the volunteer RM for 1.4 and 1.5 this is certainly a large > > > aspect of why I find it so frustrating to try and make progress with > > these > > > code lines. And yet we absolutely rely upon them at my place of > > employment, > > > so it appears we are stuck. In other discussions I've discussed why we > > > think HBase 2 is not ready for our production yet. I am perfectly > willing > > > to maintain branch-1s and raise the RMs, but not if every vote is a > slog > > > where I'm out on the street begging for votes, and receiving vetos with > > no > > > assistance for the trouble. I'm pretty sure Francis is in the same > > position > > > with branch-1.3. > > > > > > > > > On Thu, May 9, 2019 at 10:36 AM Sean Busbey <[email protected]> wrote: > > > > > > > Personally I don't think we have enough community release voting to > > > > support having closing dates on votes. This was definitely the case > on > > > > 1.2 releases. IIRC it was also true fo the last 1.3 release. > > > > > > > > I think you're already using the "I would like to close this around > > > > XXX" phrasing, but just in case I'm mistaken I figure I should call > it > > > > out. > > > > > > > > On Thu, May 9, 2019 at 12:32 PM 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 >
