> 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
