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

Reply via email to