+1 on that, https://issues.apache.org/jira/browse/HBASE-22395
for the PMC guidelines, I think it deserves its own jira and PMC member to address. On Fri, May 10, 2019 at 12:51 PM Andrew Purtell <[email protected]> wrote: > 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 >
