You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <an...@gmail.com> on 2019/05/09 16:33:54 UTC
I'm about to give up on RMing
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.
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
Something like that would be an improvement. I think my frustration stems
from a sense the burden isn't equitably shared. It also relates to what I
do as a RM which isn't policy per se. First, I run the unit suite several
times in a loop. This is scripted, but it takes time to complete and review
the results, and investigating failures and filing issues takes time too.
Then I will do the same basic checks a voter will take. Then I might run
LTT or ITBLL, which is hands on and takes more time. So far the volunteer
time spent seems perfectly reasonable and not onerous. This is not my
complaint.
When there is a veto, is the expectation the RM will follow up and fix the
problem? If it is a flaky test, that cannot be locally reproduced, this is
an additional mandate that could be costly in terms of time.
As a voter, when you cast a veto because of a compatibility issue have you
really considered if it might be allowed - our guidelines are just
guidelines, and are fuzzy by nature? Because as RM I looked at that report
too and thought it ambiguous enough to continue. The committer allowed it
implicitly by the commit. In some cases as RM I have reopened JIRAs for
compatibility problems. The recent 1.4.10RC0 is case in point. After back
and forth with the committer an incompatible change of low severity was
allowed on a Public interface. The voter should take this kind of action.
At the least we should have a JIRA reopened or filed for discussion of the
problem. What should not be considered valid, in my opinion, is a pedantic
veto that only mentions the compatibility report as reason. This is not
helpful. Guidelines, and fuzzy, if you recall.
In general for test or compatibility issues, is the expectation the RM will
fix it? That is a big assumption about the RM's personal circumstances,
wouldn't you think? Or interest in volunteering? Volunteer resources are
precious. We need to be mindful of the tradeoff here. It also applies in
code review. I think generally we strike the right balance between quality
assurance and considerations to volunteer time, but in some recent RC votes
I have gotten the impression not. No JIRAs for veto reasons. No proactive
debug of unit test failure. No patches. Hence a sense the burden for
maintaining the code isn't as equitably shared as it should be.
A policy as suggested, like a consensus that vetos should only be cast if
the issue deserves a JIRA with Critical would certainly be one way to shift
the balance. I don't think something like that is necessary. Smaller steps
as simple as giving the RM the courtesy of filing JIRAs that explain the
veto and describe steps to fix would be enough. This would shift the burden
for test failures onto the observers, who are in the best position to
understand the failure because they are the ones seeing it. It also shifts
burden on disagreements over compatibility report results. A veto for a
compatibility issue is a priori a disagreement between the voter and the
committer, and the voter and the RM. Proactive effort and remedy on the
part of the voter should be implied by this.
Thank you for your consideration.
For your consideration.
On Thu, May 9, 2019 at 9:52 AM Artem Ervits <ar...@gmail.com> wrote:
> should -1 only apply with a valid critical Jira in hand?
>
> On Thu, May 9, 2019 at 12:41 PM Andrew Purtell <an...@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 <an...@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
Re: I'm about to give up on RMing
Posted by Artem Ervits <ar...@gmail.com>.
should -1 only apply with a valid critical Jira in hand?
On Thu, May 9, 2019 at 12:41 PM Andrew Purtell <an...@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 <an...@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 <an...@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
>
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
We have a self supporting cohort of RMs, voters, and contributors for
branch-2 but not branch-1. I agree this is misaligned with the user centric
focus if we define 'user' as someone using a version that has the stable
pointer pointing to it. (smile)
If anything this thread is a plea from me to build a self supporting cohort
of RMs, voters, and contributors for branch-1. It should not be as hard as
it has been for myself, Francis, and I think Sean to get 1.x release votes
to complete. There should be more contributions to test hygiene and
compatibility concerns (when agreed upon) in branch-1.
On Thu, May 9, 2019 at 5:42 PM Sergey Shelukhin
<Se...@microsoft.com.invalid> wrote:
> That would be interesting given that in our experience prototyping on
> branch-2.1, it is really not ready for production usage.
> We fixed many bugs (mostly in the assignment; most either committed or PA
> in JIRA, internally we run with all of those) and keep finding new critical
> ones all the time (e.g. recently we started running into non-HDFS ProcWAL
> corruption, not sure yet why, lost recent repro).
> And we haven't even turned on region splitting yet ;)
>
> So 1.X line appears to be the only actually stable one right now.
>
> -----Original Message-----
> From: Andrew Purtell <ap...@apache.org>
> Sent: Thursday, May 9, 2019 10:38 AM
> To: dev <de...@hbase.apache.org>
> Cc: private@hbase.apache.org
> Subject: Re: I'm about to give up on RMing
>
> Also, it is my observation that we are really only seeing difficulty
> attracting votes when RMs offer a 1.x release candidate. Maybe this implies
> the entire branch-1 forest should EOL. This will strand major users still
> on 1.x but it appears to be the consensus will of the community, if you
> interpret a lack of voting interest in that way.
>
>
> On Thu, May 9, 2019 at 10:32 AM Andrew Purtell <ap...@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 <bu...@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
> >> <an...@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
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
RE: I'm about to give up on RMing
Posted by Sergey Shelukhin <Se...@microsoft.com.INVALID>.
That would be interesting given that in our experience prototyping on branch-2.1, it is really not ready for production usage.
We fixed many bugs (mostly in the assignment; most either committed or PA in JIRA, internally we run with all of those) and keep finding new critical ones all the time (e.g. recently we started running into non-HDFS ProcWAL corruption, not sure yet why, lost recent repro).
And we haven't even turned on region splitting yet ;)
So 1.X line appears to be the only actually stable one right now.
-----Original Message-----
From: Andrew Purtell <ap...@apache.org>
Sent: Thursday, May 9, 2019 10:38 AM
To: dev <de...@hbase.apache.org>
Cc: private@hbase.apache.org
Subject: Re: I'm about to give up on RMing
Also, it is my observation that we are really only seeing difficulty attracting votes when RMs offer a 1.x release candidate. Maybe this implies the entire branch-1 forest should EOL. This will strand major users still on 1.x but it appears to be the consensus will of the community, if you interpret a lack of voting interest in that way.
On Thu, May 9, 2019 at 10:32 AM Andrew Purtell <ap...@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 <bu...@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
>> <an...@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
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
Also, it is my observation that we are really only seeing difficulty
attracting votes when RMs offer a 1.x release candidate. Maybe this implies
the entire branch-1 forest should EOL. This will strand major users still
on 1.x but it appears to be the consensus will of the community, if you
interpret a lack of voting interest in that way.
On Thu, May 9, 2019 at 10:32 AM Andrew Purtell <ap...@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 <bu...@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 <an...@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
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
I would +1 a backport of HBASE-19735 to branch-1 if someone wanted to
contribute it. It looks like maven should just do the right thing and there
is no extra work for the RM; simply another artifact gets published. We can
include this in 1.5.0 and later?
On Thu, May 9, 2019 at 5:49 PM Artem Ervits <ar...@gmail.com> 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 <ap...@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 <bu...@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 <ap...@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 <bu...@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
> >
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: I'm about to give up on RMing
Posted by Artem Ervits <ar...@gmail.com>.
+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 <ap...@apache.org> 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 <ca...@gmail.com> 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 <ap...@apache.org>
> 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 <ar...@gmail.com>
> > 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 <ap...@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 <bu...@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
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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
>
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
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 <ca...@gmail.com> 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 <ap...@apache.org> 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 <ar...@gmail.com>
> 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 <ap...@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 <bu...@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 <bu...@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
> > > >
> > >
> >
> >
> > --
> > 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
Re: I'm about to give up on RMing
Posted by Yu Li <ca...@gmail.com>.
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 <ap...@apache.org> 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 <ar...@gmail.com> 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 <ap...@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 <bu...@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 <ap...@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 <bu...@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
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <ar...@gmail.com> 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 <ap...@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 <bu...@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 <ap...@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 <bu...@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
> >
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: I'm about to give up on RMing
Posted by Artem Ervits <ar...@gmail.com>.
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 <ap...@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 <bu...@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 <ap...@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 <bu...@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
>
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
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 <bu...@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 <ap...@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 <bu...@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
Re: I'm about to give up on RMing
Posted by Sean Busbey <bu...@apache.org>.
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 <ap...@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 <bu...@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 <an...@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 <an...@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
Re: I'm about to give up on RMing
Posted by Andrew Purtell <ap...@apache.org>.
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 <bu...@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 <an...@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 <an...@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
Re: I'm about to give up on RMing
Posted by Sean Busbey <bu...@apache.org>.
-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 <an...@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 <an...@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 <an...@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
Re: I'm about to give up on RMing
Posted by Andrew Purtell <an...@gmail.com>.
.. 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 <an...@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 <an...@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
Re: I'm about to give up on RMing
Posted by Andrew Purtell <an...@gmail.com>.
/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 <an...@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