hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Artem Ervits <artemerv...@gmail.com>
Subject Re: I'm about to give up on RMing
Date Fri, 10 May 2019 00:49:18 GMT
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 <apurtell@apache.org> 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 <busbey@apache.org> 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 <apurtell@apache.org>
> > 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 <busbey@apache.org> 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 <
> > andrew.purtell@gmail.com>
> > > > 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 <
> > andrew.purtell@gmail.com>
> > > > > 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 <
> > > > andrew.purtell@gmail.com>
> > > > > > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message