I think the answer is simply that the PMC, as part of its responsibilities, should vote on all releases, irrespective of focus. This should be an expectation of PMC membership on the project. The Chair should kindly reach out and remind PMC members who are infrequently voting of this responsibility. This should be documented in our book in the section on PMC responsibility, and if that section doesn't exist, we should add one. What do you think?
Personally my voting record on 2.x release candidates has been very spotty. This is exactly the problem I/we face with 1.x release candidates so although I complain I have to be careful not to be hypocritical. I will commit now to voting on every RC, no matter my own personal focus. There are only a handful necessary checks a PMC member must do on every release, and all of them relate to packaging, LICENSE and NOTICE files, and license auditing, which can be accomplished by running the RAT tool, by attempting to compile from source (unit tests optional), and through manual inspection of LICENSE and NOTICE files in the source distribution and embedded in a sample of the binaries. This entire process should take you less than 15 minutes, from my experience. This is the baseline. Any individual PMCer may opt to do more than the baseline, but it is optional. Personally I would also read the compatibility report, and then run the unit test suite in the background and come back to it when finished to complete the voting task. In my opinion now that is the baseline tasks any HBase PMC voter should take. Beyond that, at least for my releases, you can read the vote email to find the additional functional and performance checks I might have done and factor that in to your voting confidence. You can also run them yourselves, but is totally optional. In this way you can hopefully achieve a successful balance between your confidence in the RM and your own personal time constraints, and manage to vote more often on more release candidates. On Thu, May 9, 2019 at 9:16 PM Yu Li <[email protected]> wrote: > 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 > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
