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 <ap...@apache.org> on 2017/01/07 01:06:29 UTC
Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
HBasers,
I would like to propose extending our informal "branch RM" concept just a
bit to include the nonreleasing branches like branch-1, branch-2 (when it
exists), and master. These branches are where all commits are made passing
through down to the releasing branches targeted for the change (like,
branch-1.1, branch-1.2, branch-1.3, etc.)
The releasing branches all have their own RM. I assume that RM is
diligently monitoring its state, by way of review of commit history,
occasional execution of the unit test suite, occasional execution of the
integration tests, and has perhaps some automation in place to help with
that on a nightly or weekly basis. No matter, let's assume there is a
nonzero level of scrutiny applied to them, which leads to feedback to
committers about inappropriate commits via compat guidelines, commits which
have broken unit tests, or other indications of quality or functional
concerns. I think it would improve our overall velocity as a project if we
could also have volunteers tending the development branches upstream from
the releasing branches. Less work would fall to the RMs tending the release
branches if a common troublesome commit can be caught upstream first. In
particular I am thinking about branch-1.
I would like to volunteer to become the new RM for branch-1, to test and
refine my above proposal in practice. Unless I hear objections I will
assume by lazy consensus everyone is ok with this experiment.
What this would mean:
- JIRAs like "TestFooBar is broken on branch-1" will show up sooner, and
more likely with fix patches
- Semiregular performance reports on branch-1 code as of date X/Y/Z, can
compare with earlier reports for trending
- Occasional sweep through master history looking for appropriate
candidates for backport to branch-1, execution of said backport
- Occasional 1B row ITBLL torture tests, probably if failure with bisect
back to commit that introduced instability
What this does not mean:
- The branch-1 RM will not attempt to tell other branch RMs what or what
not to include in their release branches
- The branch-1 RM won't commit anything backported from master to any of
the release branches; it will continue to be up to the release branch RMs
what they would or would not like to be included
Also, I don't see why I couldn't spend some time looking at master now and
then.
I am going to assume our current co-RM team for branch-2 would maybe do
something similar for branch-2, once it materializes.
Thoughts? Comments? Concerns?
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Posted by Andrew Purtell <an...@gmail.com>.
> Now the authors of every issues backport new features to branch-1 after they have a patch for master, and committers help them push patches to git. So usually master and branch-1 introduce two patches for a issue at time same time.
One change would be more scrutiny of the stability and function of branch-1 (or other nonreleasing branch like branch-2) after such commit and potential for revert if a regression is not addressed within a reasonable timeframe. We don't have that today.
> If we have branch RMs, who should make a decision that if we need to backport a new feature to branch-x?
If it were me I would simply (re)open a JIRA and put up a patch to review, which would be committed after a +1. If I didn't get any response after a few days I might take that as lazy consensus for backport and commit. Someone could -1 or ask for a revert at any time, no problem. For branch-1 if a change didn't meet the compatibility guidelines for inclusion in a minor release or could not be modified to conform than it would be excluded of course. So it is the community process (committers) that decides. What's new is someone more active with testing and shepherding.
> Do we have a plan that how often we cut a new releasing branch?
When I was RM of 98 we had a minor release roughly every month. I don't think we want that here if each 1.x or 2.x minor is going to have its own RM and be maintained for a long time. Too many versions would proliferate. Or, we could become more like Phoenix, which focuses on making new minors every release cycle and rarely puts out just a patch release, only if there is a serious problem. If we were more like this, someone would volunteer to RM a new minor, it would be branched, tested, then released, and we'd move the stable pointer and all move on.
> On Jan 9, 2017, at 12:01 AM, Phil Yang <ud...@gmail.com> wrote:
>
> Like this idea. I think it will help us making non-releasing branches more
> stable, and reduce delay from cutting releasing branch to release first
> x.y.0 version which means users will meet new features earlier :)
>
> And I have two questions :)
>
>> Occasional sweep through master history looking for appropriate candidates
> for backport to branch-1, execution of said backport
>
> Now the authors of every issues backport new features to branch-1 after
> they have a patch for master, and committers help them push patches to git.
> So usually master and branch-1 introduce two patches for a issue at time
> same time. If we have branch RMs, who should make a decision that if we
> need to backport a new feature to branch-x? And when we do the backport
> work?
>
> If we have branch-RMs helping us make non-releasing branches more stable,
> we may be able to cutting new releasing branch more regular? Do we have a
> plan that how often we cut a new releasing branch?
>
> Thanks,
> Phil
>
>
> 2017-01-07 11:15 GMT+08:00 Ted Yu <yu...@gmail.com>:
>
>> bq. to see branch-1 be our new long term stable branch
>>
>> I agree.
>> Having an experienced PMC shepherding branch-1 would lay good foundation
>> for future 1.4+ and 2.x releases.
>>
>> +1 with Andrew taking up this role.
>>
>> Cheers
>>
>> On Fri, Jan 6, 2017 at 6:07 PM, Andrew Purtell <an...@gmail.com>
>> wrote:
>>
>>> I would like to see branch-1 be our new long term stable branch and so to
>>> be maintained for roughly as long as 0.98 was: three years from first
>>> release (1.0.0).
>>>
>>> It would be maintained the same way as 0.98 was. I would like to drive
>>> monthly releases but they would only be -SNAPSHOT and never advertised as
>>> an official release. So to get actual shipping code I guess I'd have to
>> bug
>>> the release RMs (smile).
>>>
>>> If the branch-1 RM felt like sweeping up changes and backporting for as
>>> long as he/she likes that would be fine with me. If I were branch-1 RM I
>>> would do that on a monthly basis. Only changes allowable on minor or
>> point
>>> revisions according to our compatibility guidelines would be allowed.
>>>
>>> We don't have a release branch RM for 1.4. I would be happy to take on
>>> that role too, but I think it premature given 1.3.0 isn't even out yet.
>>>
>>>
>>>> On Jan 6, 2017, at 5:43 PM, Mikhail Antonov <ol...@gmail.com>
>>> wrote:
>>>>
>>>> I like this idea in general (and thanks for volunteering!).
>>>>
>>>> Speaking specifically about branch-1 and given 2.0 release
>>>> discussions, is it proper time/thread to also discuss what
>>>> do we want to do with branch-1? Like, say that 1.4 would be
>>>> the last release off this line and hence branch-1 should be
>>>> turned to 1.4, and should we wind down backports to it?
>>>>
>>>> -Mikhail
>>>>
>>>>> On Fri, Jan 6, 2017 at 5:06 PM, Andrew Purtell <ap...@apache.org>
>>> wrote:
>>>>>
>>>>> HBasers,
>>>>>
>>>>> I would like to propose extending our informal "branch RM" concept
>> just
>>> a
>>>>> bit to include the nonreleasing branches like branch-1, branch-2 (when
>>> it
>>>>> exists), and master. These branches are where all commits are made
>>> passing
>>>>> through down to the releasing branches targeted for the change (like,
>>>>> branch-1.1, branch-1.2, branch-1.3, etc.)
>>>>>
>>>>> The releasing branches all have their own RM. I assume that RM is
>>>>> diligently monitoring its state, by way of review of commit history,
>>>>> occasional execution of the unit test suite, occasional execution of
>> the
>>>>> integration tests, and has perhaps some automation in place to help
>> with
>>>>> that on a nightly or weekly basis. No matter, let's assume there is a
>>>>> nonzero level of scrutiny applied to them, which leads to feedback to
>>>>> committers about inappropriate commits via compat guidelines, commits
>>> which
>>>>> have broken unit tests, or other indications of quality or functional
>>>>> concerns. I think it would improve our overall velocity as a project
>>> if we
>>>>> could also have volunteers tending the development branches upstream
>>> from
>>>>> the releasing branches. Less work would fall to the RMs tending the
>>> release
>>>>> branches if a common troublesome commit can be caught upstream first.
>> In
>>>>> particular I am thinking about branch-1.
>>>>>
>>>>> I would like to volunteer to become the new RM for branch-1, to test
>> and
>>>>> refine my above proposal in practice. Unless I hear objections I will
>>>>> assume by lazy consensus everyone is ok with this experiment.
>>>>>
>>>>> What this would mean:
>>>>>
>>>>> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner,
>>> and
>>>>> more likely with fix patches
>>>>> - Semiregular performance reports on branch-1 code as of date X/Y/Z,
>>> can
>>>>> compare with earlier reports for trending
>>>>> - Occasional sweep through master history looking for appropriate
>>>>> candidates for backport to branch-1, execution of said backport
>>>>> - Occasional 1B row ITBLL torture tests, probably if failure with
>>> bisect
>>>>> back to commit that introduced instability
>>>>>
>>>>> What this does not mean:
>>>>>
>>>>> - The branch-1 RM will not attempt to tell other branch RMs what or
>>> what
>>>>> not to include in their release branches
>>>>> - The branch-1 RM won't commit anything backported from master to
>> any
>>> of
>>>>> the release branches; it will continue to be up to the release
>> branch
>>>>> RMs
>>>>> what they would or would not like to be included
>>>>>
>>>>> Also, I don't see why I couldn't spend some time looking at master
>> now
>>> and
>>>>> then.
>>>>>
>>>>> I am going to assume our current co-RM team for branch-2 would maybe
>> do
>>>>> something similar for branch-2, once it materializes.
>>>>>
>>>>> Thoughts? Comments? Concerns?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>
>>>>> - Andy
>>>>>
>>>>> If you are given a choice, you believe you have acted freely. -
>> Raymond
>>>>> Teller (via Peter Watts)
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Michael Antonov
>>>
>>
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Phil Yang <ud...@gmail.com>.
Like this idea. I think it will help us making non-releasing branches more
stable, and reduce delay from cutting releasing branch to release first
x.y.0 version which means users will meet new features earlier :)
And I have two questions :)
> Occasional sweep through master history looking for appropriate candidates
for backport to branch-1, execution of said backport
Now the authors of every issues backport new features to branch-1 after
they have a patch for master, and committers help them push patches to git.
So usually master and branch-1 introduce two patches for a issue at time
same time. If we have branch RMs, who should make a decision that if we
need to backport a new feature to branch-x? And when we do the backport
work?
If we have branch-RMs helping us make non-releasing branches more stable,
we may be able to cutting new releasing branch more regular? Do we have a
plan that how often we cut a new releasing branch?
Thanks,
Phil
2017-01-07 11:15 GMT+08:00 Ted Yu <yu...@gmail.com>:
> bq. to see branch-1 be our new long term stable branch
>
> I agree.
> Having an experienced PMC shepherding branch-1 would lay good foundation
> for future 1.4+ and 2.x releases.
>
> +1 with Andrew taking up this role.
>
> Cheers
>
> On Fri, Jan 6, 2017 at 6:07 PM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > I would like to see branch-1 be our new long term stable branch and so to
> > be maintained for roughly as long as 0.98 was: three years from first
> > release (1.0.0).
> >
> > It would be maintained the same way as 0.98 was. I would like to drive
> > monthly releases but they would only be -SNAPSHOT and never advertised as
> > an official release. So to get actual shipping code I guess I'd have to
> bug
> > the release RMs (smile).
> >
> > If the branch-1 RM felt like sweeping up changes and backporting for as
> > long as he/she likes that would be fine with me. If I were branch-1 RM I
> > would do that on a monthly basis. Only changes allowable on minor or
> point
> > revisions according to our compatibility guidelines would be allowed.
> >
> > We don't have a release branch RM for 1.4. I would be happy to take on
> > that role too, but I think it premature given 1.3.0 isn't even out yet.
> >
> >
> > > On Jan 6, 2017, at 5:43 PM, Mikhail Antonov <ol...@gmail.com>
> > wrote:
> > >
> > > I like this idea in general (and thanks for volunteering!).
> > >
> > > Speaking specifically about branch-1 and given 2.0 release
> > > discussions, is it proper time/thread to also discuss what
> > > do we want to do with branch-1? Like, say that 1.4 would be
> > > the last release off this line and hence branch-1 should be
> > > turned to 1.4, and should we wind down backports to it?
> > >
> > > -Mikhail
> > >
> > >> On Fri, Jan 6, 2017 at 5:06 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> > >>
> > >> HBasers,
> > >>
> > >> I would like to propose extending our informal "branch RM" concept
> just
> > a
> > >> bit to include the nonreleasing branches like branch-1, branch-2 (when
> > it
> > >> exists), and master. These branches are where all commits are made
> > passing
> > >> through down to the releasing branches targeted for the change (like,
> > >> branch-1.1, branch-1.2, branch-1.3, etc.)
> > >>
> > >> The releasing branches all have their own RM. I assume that RM is
> > >> diligently monitoring its state, by way of review of commit history,
> > >> occasional execution of the unit test suite, occasional execution of
> the
> > >> integration tests, and has perhaps some automation in place to help
> with
> > >> that on a nightly or weekly basis. No matter, let's assume there is a
> > >> nonzero level of scrutiny applied to them, which leads to feedback to
> > >> committers about inappropriate commits via compat guidelines, commits
> > which
> > >> have broken unit tests, or other indications of quality or functional
> > >> concerns. I think it would improve our overall velocity as a project
> > if we
> > >> could also have volunteers tending the development branches upstream
> > from
> > >> the releasing branches. Less work would fall to the RMs tending the
> > release
> > >> branches if a common troublesome commit can be caught upstream first.
> In
> > >> particular I am thinking about branch-1.
> > >>
> > >> I would like to volunteer to become the new RM for branch-1, to test
> and
> > >> refine my above proposal in practice. Unless I hear objections I will
> > >> assume by lazy consensus everyone is ok with this experiment.
> > >>
> > >> What this would mean:
> > >>
> > >> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner,
> > and
> > >> more likely with fix patches
> > >> - Semiregular performance reports on branch-1 code as of date X/Y/Z,
> > can
> > >> compare with earlier reports for trending
> > >> - Occasional sweep through master history looking for appropriate
> > >> candidates for backport to branch-1, execution of said backport
> > >> - Occasional 1B row ITBLL torture tests, probably if failure with
> > bisect
> > >> back to commit that introduced instability
> > >>
> > >> What this does not mean:
> > >>
> > >> - The branch-1 RM will not attempt to tell other branch RMs what or
> > what
> > >> not to include in their release branches
> > >> - The branch-1 RM won't commit anything backported from master to
> any
> > of
> > >> the release branches; it will continue to be up to the release
> branch
> > >> RMs
> > >> what they would or would not like to be included
> > >>
> > >> Also, I don't see why I couldn't spend some time looking at master
> now
> > and
> > >> then.
> > >>
> > >> I am going to assume our current co-RM team for branch-2 would maybe
> do
> > >> something similar for branch-2, once it materializes.
> > >>
> > >> Thoughts? Comments? Concerns?
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >>
> > >> - Andy
> > >>
> > >> If you are given a choice, you believe you have acted freely. -
> Raymond
> > >> Teller (via Peter Watts)
> > >>
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Michael Antonov
> >
>
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Ted Yu <yu...@gmail.com>.
bq. to see branch-1 be our new long term stable branch
I agree.
Having an experienced PMC shepherding branch-1 would lay good foundation
for future 1.4+ and 2.x releases.
+1 with Andrew taking up this role.
Cheers
On Fri, Jan 6, 2017 at 6:07 PM, Andrew Purtell <an...@gmail.com>
wrote:
> I would like to see branch-1 be our new long term stable branch and so to
> be maintained for roughly as long as 0.98 was: three years from first
> release (1.0.0).
>
> It would be maintained the same way as 0.98 was. I would like to drive
> monthly releases but they would only be -SNAPSHOT and never advertised as
> an official release. So to get actual shipping code I guess I'd have to bug
> the release RMs (smile).
>
> If the branch-1 RM felt like sweeping up changes and backporting for as
> long as he/she likes that would be fine with me. If I were branch-1 RM I
> would do that on a monthly basis. Only changes allowable on minor or point
> revisions according to our compatibility guidelines would be allowed.
>
> We don't have a release branch RM for 1.4. I would be happy to take on
> that role too, but I think it premature given 1.3.0 isn't even out yet.
>
>
> > On Jan 6, 2017, at 5:43 PM, Mikhail Antonov <ol...@gmail.com>
> wrote:
> >
> > I like this idea in general (and thanks for volunteering!).
> >
> > Speaking specifically about branch-1 and given 2.0 release
> > discussions, is it proper time/thread to also discuss what
> > do we want to do with branch-1? Like, say that 1.4 would be
> > the last release off this line and hence branch-1 should be
> > turned to 1.4, and should we wind down backports to it?
> >
> > -Mikhail
> >
> >> On Fri, Jan 6, 2017 at 5:06 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> >>
> >> HBasers,
> >>
> >> I would like to propose extending our informal "branch RM" concept just
> a
> >> bit to include the nonreleasing branches like branch-1, branch-2 (when
> it
> >> exists), and master. These branches are where all commits are made
> passing
> >> through down to the releasing branches targeted for the change (like,
> >> branch-1.1, branch-1.2, branch-1.3, etc.)
> >>
> >> The releasing branches all have their own RM. I assume that RM is
> >> diligently monitoring its state, by way of review of commit history,
> >> occasional execution of the unit test suite, occasional execution of the
> >> integration tests, and has perhaps some automation in place to help with
> >> that on a nightly or weekly basis. No matter, let's assume there is a
> >> nonzero level of scrutiny applied to them, which leads to feedback to
> >> committers about inappropriate commits via compat guidelines, commits
> which
> >> have broken unit tests, or other indications of quality or functional
> >> concerns. I think it would improve our overall velocity as a project
> if we
> >> could also have volunteers tending the development branches upstream
> from
> >> the releasing branches. Less work would fall to the RMs tending the
> release
> >> branches if a common troublesome commit can be caught upstream first. In
> >> particular I am thinking about branch-1.
> >>
> >> I would like to volunteer to become the new RM for branch-1, to test and
> >> refine my above proposal in practice. Unless I hear objections I will
> >> assume by lazy consensus everyone is ok with this experiment.
> >>
> >> What this would mean:
> >>
> >> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner,
> and
> >> more likely with fix patches
> >> - Semiregular performance reports on branch-1 code as of date X/Y/Z,
> can
> >> compare with earlier reports for trending
> >> - Occasional sweep through master history looking for appropriate
> >> candidates for backport to branch-1, execution of said backport
> >> - Occasional 1B row ITBLL torture tests, probably if failure with
> bisect
> >> back to commit that introduced instability
> >>
> >> What this does not mean:
> >>
> >> - The branch-1 RM will not attempt to tell other branch RMs what or
> what
> >> not to include in their release branches
> >> - The branch-1 RM won't commit anything backported from master to any
> of
> >> the release branches; it will continue to be up to the release branch
> >> RMs
> >> what they would or would not like to be included
> >>
> >> Also, I don't see why I couldn't spend some time looking at master now
> and
> >> then.
> >>
> >> I am going to assume our current co-RM team for branch-2 would maybe do
> >> something similar for branch-2, once it materializes.
> >>
> >> Thoughts? Comments? Concerns?
> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >> - Andy
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymond
> >> Teller (via Peter Watts)
> >>
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
>
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Andrew Purtell <ap...@apache.org>.
As branch-1 "RM" I don't need to be in the loop when a committer wants to
commit something there, and wouldn't have the bandwidth for it anyway. So
if someone wants to put something in branch-N.M, feel free to commit it to
master, then branch-N, then branch-N.M, as is our current workflow. If the
commit is bad and not dealt with in a timely manner it may be reverted from
both places (potentially by me). This is also not a change, except someone
is paying more attention to branch-1. I also agree that if we've reverted
something from branch-N then it has to be reverted from branch-N.M, and I
would expect the PMC to enforce this sanity. Likewise, if something has
been released on branch-N.M, then it cannot be reverted from branch-N. That
kind of inconsistency in commit lineage would make things unmanageable.
Th most likely case where the branch-N maintainer's judgement would come in
conflict with a committer's judgement and need resolution would be if a
commit is made that causes observed instability, or performance regression,
or is a (potentially, debatable) violation of compatibility guidelines, and
the branch-N maintainer executes a revert of the commit from branch-N and
any children branch-N.M, so long as the change has not been released.
On Mon, Jan 9, 2017 at 1:39 PM, Mikhail Antonov <ol...@gmail.com>
wrote:
> One question to reiterate on the commit flow..
>
> I think we agreed, as you said, that branch-N RM won't dictate what to
> backport and what not to released branches maintainers, but
> at least logically I'd still treat that as an additional "line of defense"
> for too big, too risky or otherwise questionable commits. I.e. if branch-N
> RM
> doesn't feel like porting patch from master to branch-N, it's surely isn't
> safe enough to port to branch-N.M? Thoughts?
>
> -Mikhail
>
> On Mon, Jan 9, 2017 at 12:43 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Good, I think we are on the same page regards a long term maintainer for
> > branch-1. I can make a multi year commitment like I did with 0.98. How
> that
> > works with respect to branching for minor releases we can figure out. My
> > thought is anytime someone wants to branch off to make a minor release,
> RM
> > it, and run with it, that's great, and the more on the project who do
> that
> > the better off we will be with the releasing work well spread around. At
> > the same time people won't have infinite time to maintain minor branches
> > and generate patch releases, so when the maintainer of a minor branch
> feels
> > like moving on, whenever that is, this is perfectly fine. This is
> basically
> > the current situation, except maybe minor branch RMs are feeling they
> have
> > themselves taken on a long term commitment (this can change, up to the
> > individual, as it has always been), and there is no maintainer on the
> > upstream branch (this will change).
> >
> >
> > On Mon, Jan 9, 2017 at 10:35 AM, Mikhail Antonov <ol...@gmail.com>
> > wrote:
> >
> > > I should say I was talking more about "should these things be discussed
> > > together or separately", not any particular direction we should
> > > or should not take, as I didn't want to accidentally steal the topic.
> > >
> > > But speaking specifically on that.. saying that we're going to maintain
> > > branch-1 lines until at least Feb 2018 definitely makes total sense to
> > me.
> > > 2 years overlap with 2.0 might be something we'd want to discuss in
> some
> > > more depth.
> > >
> > > -Mikhail
> > >
> > > On Mon, Jan 9, 2017 at 10:26 AM, Sean Busbey <bu...@apache.org>
> wrote:
> > >
> > > > On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov <
> olorinbant@gmail.com>
> > > > wrote:
> > > > > ...
> > > > >
> > > > > Speaking specifically about branch-1 and given 2.0 release
> > > > > discussions, is it proper time/thread to also discuss what
> > > > > do we want to do with branch-1? Like, say that 1.4 would be
> > > > > the last release off this line and hence branch-1 should be
> > > > > turned to 1.4, and should we wind down backports to it?
> > > >
> > > > On Fri, Jan 6, 2017 at 8:07 PM, Andrew Purtell <
> > andrew.purtell@gmail.com
> > > >
> > > > wrote:
> > > > > I would like to see branch-1 be our new long term stable branch and
> > so
> > > > to be maintained for roughly as long as 0.98 was: three years from
> > first
> > > > release (1.0.0).
> > > > >
> > > > > ...
> > > >
> > > > I would definitely not be comfortable retiring branch-1 any time this
> > > > CY, given the unknown state of both the 2.0 release process and how
> > > > long that branch has been without a release. Three years from 1.0.0
> > > > puts us at February 2018. The 0.98 branch had the benefit of nearly 2
> > > > years overlap with branch-1 releases; should branch-1 have a similar
> > > > window with branch-2?
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Michael Antonov
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Mikhail Antonov <ol...@gmail.com>.
One question to reiterate on the commit flow..
I think we agreed, as you said, that branch-N RM won't dictate what to
backport and what not to released branches maintainers, but
at least logically I'd still treat that as an additional "line of defense"
for too big, too risky or otherwise questionable commits. I.e. if branch-N
RM
doesn't feel like porting patch from master to branch-N, it's surely isn't
safe enough to port to branch-N.M? Thoughts?
-Mikhail
On Mon, Jan 9, 2017 at 12:43 PM, Andrew Purtell <ap...@apache.org> wrote:
> Good, I think we are on the same page regards a long term maintainer for
> branch-1. I can make a multi year commitment like I did with 0.98. How that
> works with respect to branching for minor releases we can figure out. My
> thought is anytime someone wants to branch off to make a minor release, RM
> it, and run with it, that's great, and the more on the project who do that
> the better off we will be with the releasing work well spread around. At
> the same time people won't have infinite time to maintain minor branches
> and generate patch releases, so when the maintainer of a minor branch feels
> like moving on, whenever that is, this is perfectly fine. This is basically
> the current situation, except maybe minor branch RMs are feeling they have
> themselves taken on a long term commitment (this can change, up to the
> individual, as it has always been), and there is no maintainer on the
> upstream branch (this will change).
>
>
> On Mon, Jan 9, 2017 at 10:35 AM, Mikhail Antonov <ol...@gmail.com>
> wrote:
>
> > I should say I was talking more about "should these things be discussed
> > together or separately", not any particular direction we should
> > or should not take, as I didn't want to accidentally steal the topic.
> >
> > But speaking specifically on that.. saying that we're going to maintain
> > branch-1 lines until at least Feb 2018 definitely makes total sense to
> me.
> > 2 years overlap with 2.0 might be something we'd want to discuss in some
> > more depth.
> >
> > -Mikhail
> >
> > On Mon, Jan 9, 2017 at 10:26 AM, Sean Busbey <bu...@apache.org> wrote:
> >
> > > On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov <ol...@gmail.com>
> > > wrote:
> > > > ...
> > > >
> > > > Speaking specifically about branch-1 and given 2.0 release
> > > > discussions, is it proper time/thread to also discuss what
> > > > do we want to do with branch-1? Like, say that 1.4 would be
> > > > the last release off this line and hence branch-1 should be
> > > > turned to 1.4, and should we wind down backports to it?
> > >
> > > On Fri, Jan 6, 2017 at 8:07 PM, Andrew Purtell <
> andrew.purtell@gmail.com
> > >
> > > wrote:
> > > > I would like to see branch-1 be our new long term stable branch and
> so
> > > to be maintained for roughly as long as 0.98 was: three years from
> first
> > > release (1.0.0).
> > > >
> > > > ...
> > >
> > > I would definitely not be comfortable retiring branch-1 any time this
> > > CY, given the unknown state of both the 2.0 release process and how
> > > long that branch has been without a release. Three years from 1.0.0
> > > puts us at February 2018. The 0.98 branch had the benefit of nearly 2
> > > years overlap with branch-1 releases; should branch-1 have a similar
> > > window with branch-2?
> > >
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
--
Thanks,
Michael Antonov
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Andrew Purtell <ap...@apache.org>.
Good, I think we are on the same page regards a long term maintainer for
branch-1. I can make a multi year commitment like I did with 0.98. How that
works with respect to branching for minor releases we can figure out. My
thought is anytime someone wants to branch off to make a minor release, RM
it, and run with it, that's great, and the more on the project who do that
the better off we will be with the releasing work well spread around. At
the same time people won't have infinite time to maintain minor branches
and generate patch releases, so when the maintainer of a minor branch feels
like moving on, whenever that is, this is perfectly fine. This is basically
the current situation, except maybe minor branch RMs are feeling they have
themselves taken on a long term commitment (this can change, up to the
individual, as it has always been), and there is no maintainer on the
upstream branch (this will change).
On Mon, Jan 9, 2017 at 10:35 AM, Mikhail Antonov <ol...@gmail.com>
wrote:
> I should say I was talking more about "should these things be discussed
> together or separately", not any particular direction we should
> or should not take, as I didn't want to accidentally steal the topic.
>
> But speaking specifically on that.. saying that we're going to maintain
> branch-1 lines until at least Feb 2018 definitely makes total sense to me.
> 2 years overlap with 2.0 might be something we'd want to discuss in some
> more depth.
>
> -Mikhail
>
> On Mon, Jan 9, 2017 at 10:26 AM, Sean Busbey <bu...@apache.org> wrote:
>
> > On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov <ol...@gmail.com>
> > wrote:
> > > ...
> > >
> > > Speaking specifically about branch-1 and given 2.0 release
> > > discussions, is it proper time/thread to also discuss what
> > > do we want to do with branch-1? Like, say that 1.4 would be
> > > the last release off this line and hence branch-1 should be
> > > turned to 1.4, and should we wind down backports to it?
> >
> > On Fri, Jan 6, 2017 at 8:07 PM, Andrew Purtell <andrew.purtell@gmail.com
> >
> > wrote:
> > > I would like to see branch-1 be our new long term stable branch and so
> > to be maintained for roughly as long as 0.98 was: three years from first
> > release (1.0.0).
> > >
> > > ...
> >
> > I would definitely not be comfortable retiring branch-1 any time this
> > CY, given the unknown state of both the 2.0 release process and how
> > long that branch has been without a release. Three years from 1.0.0
> > puts us at February 2018. The 0.98 branch had the benefit of nearly 2
> > years overlap with branch-1 releases; should branch-1 have a similar
> > window with branch-2?
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Mikhail Antonov <ol...@gmail.com>.
I should say I was talking more about "should these things be discussed
together or separately", not any particular direction we should
or should not take, as I didn't want to accidentally steal the topic.
But speaking specifically on that.. saying that we're going to maintain
branch-1 lines until at least Feb 2018 definitely makes total sense to me.
2 years overlap with 2.0 might be something we'd want to discuss in some
more depth.
-Mikhail
On Mon, Jan 9, 2017 at 10:26 AM, Sean Busbey <bu...@apache.org> wrote:
> On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov <ol...@gmail.com>
> wrote:
> > ...
> >
> > Speaking specifically about branch-1 and given 2.0 release
> > discussions, is it proper time/thread to also discuss what
> > do we want to do with branch-1? Like, say that 1.4 would be
> > the last release off this line and hence branch-1 should be
> > turned to 1.4, and should we wind down backports to it?
>
> On Fri, Jan 6, 2017 at 8:07 PM, Andrew Purtell <an...@gmail.com>
> wrote:
> > I would like to see branch-1 be our new long term stable branch and so
> to be maintained for roughly as long as 0.98 was: three years from first
> release (1.0.0).
> >
> > ...
>
> I would definitely not be comfortable retiring branch-1 any time this
> CY, given the unknown state of both the 2.0 release process and how
> long that branch has been without a release. Three years from 1.0.0
> puts us at February 2018. The 0.98 branch had the benefit of nearly 2
> years overlap with branch-1 releases; should branch-1 have a similar
> window with branch-2?
>
--
Thanks,
Michael Antonov
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Sean Busbey <bu...@apache.org>.
On Fri, Jan 6, 2017 at 7:43 PM, Mikhail Antonov <ol...@gmail.com> wrote:
> ...
>
> Speaking specifically about branch-1 and given 2.0 release
> discussions, is it proper time/thread to also discuss what
> do we want to do with branch-1? Like, say that 1.4 would be
> the last release off this line and hence branch-1 should be
> turned to 1.4, and should we wind down backports to it?
On Fri, Jan 6, 2017 at 8:07 PM, Andrew Purtell <an...@gmail.com> wrote:
> I would like to see branch-1 be our new long term stable branch and so to be maintained for roughly as long as 0.98 was: three years from first release (1.0.0).
>
> ...
I would definitely not be comfortable retiring branch-1 any time this
CY, given the unknown state of both the 2.0 release process and how
long that branch has been without a release. Three years from 1.0.0
puts us at February 2018. The 0.98 branch had the benefit of nearly 2
years overlap with branch-1 releases; should branch-1 have a similar
window with branch-2?
Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Posted by Andrew Purtell <an...@gmail.com>.
I would like to see branch-1 be our new long term stable branch and so to be maintained for roughly as long as 0.98 was: three years from first release (1.0.0).
It would be maintained the same way as 0.98 was. I would like to drive monthly releases but they would only be -SNAPSHOT and never advertised as an official release. So to get actual shipping code I guess I'd have to bug the release RMs (smile).
If the branch-1 RM felt like sweeping up changes and backporting for as long as he/she likes that would be fine with me. If I were branch-1 RM I would do that on a monthly basis. Only changes allowable on minor or point revisions according to our compatibility guidelines would be allowed.
We don't have a release branch RM for 1.4. I would be happy to take on that role too, but I think it premature given 1.3.0 isn't even out yet.
> On Jan 6, 2017, at 5:43 PM, Mikhail Antonov <ol...@gmail.com> wrote:
>
> I like this idea in general (and thanks for volunteering!).
>
> Speaking specifically about branch-1 and given 2.0 release
> discussions, is it proper time/thread to also discuss what
> do we want to do with branch-1? Like, say that 1.4 would be
> the last release off this line and hence branch-1 should be
> turned to 1.4, and should we wind down backports to it?
>
> -Mikhail
>
>> On Fri, Jan 6, 2017 at 5:06 PM, Andrew Purtell <ap...@apache.org> wrote:
>>
>> HBasers,
>>
>> I would like to propose extending our informal "branch RM" concept just a
>> bit to include the nonreleasing branches like branch-1, branch-2 (when it
>> exists), and master. These branches are where all commits are made passing
>> through down to the releasing branches targeted for the change (like,
>> branch-1.1, branch-1.2, branch-1.3, etc.)
>>
>> The releasing branches all have their own RM. I assume that RM is
>> diligently monitoring its state, by way of review of commit history,
>> occasional execution of the unit test suite, occasional execution of the
>> integration tests, and has perhaps some automation in place to help with
>> that on a nightly or weekly basis. No matter, let's assume there is a
>> nonzero level of scrutiny applied to them, which leads to feedback to
>> committers about inappropriate commits via compat guidelines, commits which
>> have broken unit tests, or other indications of quality or functional
>> concerns. I think it would improve our overall velocity as a project if we
>> could also have volunteers tending the development branches upstream from
>> the releasing branches. Less work would fall to the RMs tending the release
>> branches if a common troublesome commit can be caught upstream first. In
>> particular I am thinking about branch-1.
>>
>> I would like to volunteer to become the new RM for branch-1, to test and
>> refine my above proposal in practice. Unless I hear objections I will
>> assume by lazy consensus everyone is ok with this experiment.
>>
>> What this would mean:
>>
>> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner, and
>> more likely with fix patches
>> - Semiregular performance reports on branch-1 code as of date X/Y/Z, can
>> compare with earlier reports for trending
>> - Occasional sweep through master history looking for appropriate
>> candidates for backport to branch-1, execution of said backport
>> - Occasional 1B row ITBLL torture tests, probably if failure with bisect
>> back to commit that introduced instability
>>
>> What this does not mean:
>>
>> - The branch-1 RM will not attempt to tell other branch RMs what or what
>> not to include in their release branches
>> - The branch-1 RM won't commit anything backported from master to any of
>> the release branches; it will continue to be up to the release branch
>> RMs
>> what they would or would not like to be included
>>
>> Also, I don't see why I couldn't spend some time looking at master now and
>> then.
>>
>> I am going to assume our current co-RM team for branch-2 would maybe do
>> something similar for branch-2, once it materializes.
>>
>> Thoughts? Comments? Concerns?
>>
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> If you are given a choice, you believe you have acted freely. - Raymond
>> Teller (via Peter Watts)
>>
>
>
>
> --
> Thanks,
> Michael Antonov
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Mikhail Antonov <ol...@gmail.com>.
I like this idea in general (and thanks for volunteering!).
Speaking specifically about branch-1 and given 2.0 release
discussions, is it proper time/thread to also discuss what
do we want to do with branch-1? Like, say that 1.4 would be
the last release off this line and hence branch-1 should be
turned to 1.4, and should we wind down backports to it?
-Mikhail
On Fri, Jan 6, 2017 at 5:06 PM, Andrew Purtell <ap...@apache.org> wrote:
> HBasers,
>
> I would like to propose extending our informal "branch RM" concept just a
> bit to include the nonreleasing branches like branch-1, branch-2 (when it
> exists), and master. These branches are where all commits are made passing
> through down to the releasing branches targeted for the change (like,
> branch-1.1, branch-1.2, branch-1.3, etc.)
>
> The releasing branches all have their own RM. I assume that RM is
> diligently monitoring its state, by way of review of commit history,
> occasional execution of the unit test suite, occasional execution of the
> integration tests, and has perhaps some automation in place to help with
> that on a nightly or weekly basis. No matter, let's assume there is a
> nonzero level of scrutiny applied to them, which leads to feedback to
> committers about inappropriate commits via compat guidelines, commits which
> have broken unit tests, or other indications of quality or functional
> concerns. I think it would improve our overall velocity as a project if we
> could also have volunteers tending the development branches upstream from
> the releasing branches. Less work would fall to the RMs tending the release
> branches if a common troublesome commit can be caught upstream first. In
> particular I am thinking about branch-1.
>
> I would like to volunteer to become the new RM for branch-1, to test and
> refine my above proposal in practice. Unless I hear objections I will
> assume by lazy consensus everyone is ok with this experiment.
>
> What this would mean:
>
> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner, and
> more likely with fix patches
> - Semiregular performance reports on branch-1 code as of date X/Y/Z, can
> compare with earlier reports for trending
> - Occasional sweep through master history looking for appropriate
> candidates for backport to branch-1, execution of said backport
> - Occasional 1B row ITBLL torture tests, probably if failure with bisect
> back to commit that introduced instability
>
> What this does not mean:
>
> - The branch-1 RM will not attempt to tell other branch RMs what or what
> not to include in their release branches
> - The branch-1 RM won't commit anything backported from master to any of
> the release branches; it will continue to be up to the release branch
> RMs
> what they would or would not like to be included
>
> Also, I don't see why I couldn't spend some time looking at master now and
> then.
>
> I am going to assume our current co-RM team for branch-2 would maybe do
> something similar for branch-2, once it materializes.
>
> Thoughts? Comments? Concerns?
>
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
--
Thanks,
Michael Antonov
Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Posted by Andrew Purtell <an...@gmail.com>.
Thanks everyone for the discussion. I'll informally watch branch-1. Planning on monthly passes for cherry picks and release testing as I did for 0.98, but in this case the output will be nonrelease snapshots. Release RMs will not see pick backs from me. The changes you can expect is reverts if we something problematic and it has not gone out in a release yet. Looking forward to a productive LTS of branch-1.
> On Jan 11, 2017, at 1:43 PM, Enis Söztutar <en...@apache.org> wrote:
>
> I was thinking in similar lines that the RM for 1.X which is the next one
> would be managing branch-1, but I am also concerned about the large gap in
> terms of timing. For example, unless we are close to 1.4, an 1.4 RM will
> not materialize.
>
> So, I am in favor of having an informal branch-1 RM that will work with the
> 1.x RMs. An +1 for Andrew for that role.
>
> Enis
>
> On Wed, Jan 11, 2017 at 1:17 PM, Andrew Purtell <an...@gmail.com>
> wrote:
>
>> We could do it that way but there would be nobody promising to watch
>> branch-1 for any length of time. I'd like to do that. We could do this
>> alternative for branch-2. And it makes sense once we have this sorted to
>> write down what we'd like to do.
>>
>>
>>> On Jan 9, 2017, at 3:27 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>>>
>>> Somewhat late to the reply --
>>>
>>> Does it make sense, for branch-1, to have the person planning to RM the
>>> next minor release act as the RM for the major-level branch? That person
>>> would hand responsibility to the next minor RM upon cutting the
>>> stabilization branch.
>>>
>>> This could be applied to master/branch-2 as well, but the further away we
>>> get from a target release date, the more nebulous the RM role becomes.
>>>
>>>> On Fri, Jan 6, 2017 at 5:07 PM Andrew Purtell <ap...@apache.org>
>> wrote:
>>>>
>>>> HBasers,
>>>>
>>>>
>>>>
>>>> I would like to propose extending our informal "branch RM" concept just
>> a
>>>>
>>>> bit to include the nonreleasing branches like branch-1, branch-2 (when
>> it
>>>>
>>>> exists), and master. These branches are where all commits are made
>> passing
>>>>
>>>> through down to the releasing branches targeted for the change (like,
>>>>
>>>> branch-1.1, branch-1.2, branch-1.3, etc.)
>>>>
>>>>
>>>>
>>>> The releasing branches all have their own RM. I assume that RM is
>>>>
>>>> diligently monitoring its state, by way of review of commit history,
>>>>
>>>> occasional execution of the unit test suite, occasional execution of the
>>>>
>>>> integration tests, and has perhaps some automation in place to help with
>>>>
>>>> that on a nightly or weekly basis. No matter, let's assume there is a
>>>>
>>>> nonzero level of scrutiny applied to them, which leads to feedback to
>>>>
>>>> committers about inappropriate commits via compat guidelines, commits
>> which
>>>>
>>>> have broken unit tests, or other indications of quality or functional
>>>>
>>>> concerns. I think it would improve our overall velocity as a project
>> if we
>>>>
>>>> could also have volunteers tending the development branches upstream
>> from
>>>>
>>>> the releasing branches. Less work would fall to the RMs tending the
>> release
>>>>
>>>> branches if a common troublesome commit can be caught upstream first. In
>>>>
>>>> particular I am thinking about branch-1.
>>>>
>>>>
>>>>
>>>> I would like to volunteer to become the new RM for branch-1, to test and
>>>>
>>>> refine my above proposal in practice. Unless I hear objections I will
>>>>
>>>> assume by lazy consensus everyone is ok with this experiment.
>>>>
>>>>
>>>>
>>>> What this would mean:
>>>>
>>>>
>>>>
>>>> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner,
>> and
>>>>
>>>> more likely with fix patches
>>>>
>>>> - Semiregular performance reports on branch-1 code as of date X/Y/Z,
>> can
>>>>
>>>> compare with earlier reports for trending
>>>>
>>>> - Occasional sweep through master history looking for appropriate
>>>>
>>>> candidates for backport to branch-1, execution of said backport
>>>>
>>>> - Occasional 1B row ITBLL torture tests, probably if failure with
>> bisect
>>>>
>>>> back to commit that introduced instability
>>>>
>>>>
>>>>
>>>> What this does not mean:
>>>>
>>>>
>>>>
>>>> - The branch-1 RM will not attempt to tell other branch RMs what or
>> what
>>>>
>>>> not to include in their release branches
>>>>
>>>> - The branch-1 RM won't commit anything backported from master to any
>> of
>>>>
>>>> the release branches; it will continue to be up to the release branch
>>>> RMs
>>>>
>>>> what they would or would not like to be included
>>>>
>>>>
>>>>
>>>> Also, I don't see why I couldn't spend some time looking at master now
>> and
>>>>
>>>> then.
>>>>
>>>>
>>>>
>>>> I am going to assume our current co-RM team for branch-2 would maybe do
>>>>
>>>> something similar for branch-2, once it materializes.
>>>>
>>>>
>>>>
>>>> Thoughts? Comments? Concerns?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>>
>>>>
>>>>
>>>> - Andy
>>>>
>>>>
>>>>
>>>> If you are given a choice, you believe you have acted freely. - Raymond
>>>>
>>>> Teller (via Peter Watts)
>>>>
>>>>
>>
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Enis Söztutar <en...@apache.org>.
I was thinking in similar lines that the RM for 1.X which is the next one
would be managing branch-1, but I am also concerned about the large gap in
terms of timing. For example, unless we are close to 1.4, an 1.4 RM will
not materialize.
So, I am in favor of having an informal branch-1 RM that will work with the
1.x RMs. An +1 for Andrew for that role.
Enis
On Wed, Jan 11, 2017 at 1:17 PM, Andrew Purtell <an...@gmail.com>
wrote:
> We could do it that way but there would be nobody promising to watch
> branch-1 for any length of time. I'd like to do that. We could do this
> alternative for branch-2. And it makes sense once we have this sorted to
> write down what we'd like to do.
>
>
> > On Jan 9, 2017, at 3:27 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> >
> > Somewhat late to the reply --
> >
> > Does it make sense, for branch-1, to have the person planning to RM the
> > next minor release act as the RM for the major-level branch? That person
> > would hand responsibility to the next minor RM upon cutting the
> > stabilization branch.
> >
> > This could be applied to master/branch-2 as well, but the further away we
> > get from a target release date, the more nebulous the RM role becomes.
> >
> >> On Fri, Jan 6, 2017 at 5:07 PM Andrew Purtell <ap...@apache.org>
> wrote:
> >>
> >> HBasers,
> >>
> >>
> >>
> >> I would like to propose extending our informal "branch RM" concept just
> a
> >>
> >> bit to include the nonreleasing branches like branch-1, branch-2 (when
> it
> >>
> >> exists), and master. These branches are where all commits are made
> passing
> >>
> >> through down to the releasing branches targeted for the change (like,
> >>
> >> branch-1.1, branch-1.2, branch-1.3, etc.)
> >>
> >>
> >>
> >> The releasing branches all have their own RM. I assume that RM is
> >>
> >> diligently monitoring its state, by way of review of commit history,
> >>
> >> occasional execution of the unit test suite, occasional execution of the
> >>
> >> integration tests, and has perhaps some automation in place to help with
> >>
> >> that on a nightly or weekly basis. No matter, let's assume there is a
> >>
> >> nonzero level of scrutiny applied to them, which leads to feedback to
> >>
> >> committers about inappropriate commits via compat guidelines, commits
> which
> >>
> >> have broken unit tests, or other indications of quality or functional
> >>
> >> concerns. I think it would improve our overall velocity as a project
> if we
> >>
> >> could also have volunteers tending the development branches upstream
> from
> >>
> >> the releasing branches. Less work would fall to the RMs tending the
> release
> >>
> >> branches if a common troublesome commit can be caught upstream first. In
> >>
> >> particular I am thinking about branch-1.
> >>
> >>
> >>
> >> I would like to volunteer to become the new RM for branch-1, to test and
> >>
> >> refine my above proposal in practice. Unless I hear objections I will
> >>
> >> assume by lazy consensus everyone is ok with this experiment.
> >>
> >>
> >>
> >> What this would mean:
> >>
> >>
> >>
> >> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner,
> and
> >>
> >> more likely with fix patches
> >>
> >> - Semiregular performance reports on branch-1 code as of date X/Y/Z,
> can
> >>
> >> compare with earlier reports for trending
> >>
> >> - Occasional sweep through master history looking for appropriate
> >>
> >> candidates for backport to branch-1, execution of said backport
> >>
> >> - Occasional 1B row ITBLL torture tests, probably if failure with
> bisect
> >>
> >> back to commit that introduced instability
> >>
> >>
> >>
> >> What this does not mean:
> >>
> >>
> >>
> >> - The branch-1 RM will not attempt to tell other branch RMs what or
> what
> >>
> >> not to include in their release branches
> >>
> >> - The branch-1 RM won't commit anything backported from master to any
> of
> >>
> >> the release branches; it will continue to be up to the release branch
> >> RMs
> >>
> >> what they would or would not like to be included
> >>
> >>
> >>
> >> Also, I don't see why I couldn't spend some time looking at master now
> and
> >>
> >> then.
> >>
> >>
> >>
> >> I am going to assume our current co-RM team for branch-2 would maybe do
> >>
> >> something similar for branch-2, once it materializes.
> >>
> >>
> >>
> >> Thoughts? Comments? Concerns?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >>
> >>
> >>
> >> - Andy
> >>
> >>
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymond
> >>
> >> Teller (via Peter Watts)
> >>
> >>
>
Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Posted by Andrew Purtell <an...@gmail.com>.
We could do it that way but there would be nobody promising to watch branch-1 for any length of time. I'd like to do that. We could do this alternative for branch-2. And it makes sense once we have this sorted to write down what we'd like to do.
> On Jan 9, 2017, at 3:27 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> Somewhat late to the reply --
>
> Does it make sense, for branch-1, to have the person planning to RM the
> next minor release act as the RM for the major-level branch? That person
> would hand responsibility to the next minor RM upon cutting the
> stabilization branch.
>
> This could be applied to master/branch-2 as well, but the further away we
> get from a target release date, the more nebulous the RM role becomes.
>
>> On Fri, Jan 6, 2017 at 5:07 PM Andrew Purtell <ap...@apache.org> wrote:
>>
>> HBasers,
>>
>>
>>
>> I would like to propose extending our informal "branch RM" concept just a
>>
>> bit to include the nonreleasing branches like branch-1, branch-2 (when it
>>
>> exists), and master. These branches are where all commits are made passing
>>
>> through down to the releasing branches targeted for the change (like,
>>
>> branch-1.1, branch-1.2, branch-1.3, etc.)
>>
>>
>>
>> The releasing branches all have their own RM. I assume that RM is
>>
>> diligently monitoring its state, by way of review of commit history,
>>
>> occasional execution of the unit test suite, occasional execution of the
>>
>> integration tests, and has perhaps some automation in place to help with
>>
>> that on a nightly or weekly basis. No matter, let's assume there is a
>>
>> nonzero level of scrutiny applied to them, which leads to feedback to
>>
>> committers about inappropriate commits via compat guidelines, commits which
>>
>> have broken unit tests, or other indications of quality or functional
>>
>> concerns. I think it would improve our overall velocity as a project if we
>>
>> could also have volunteers tending the development branches upstream from
>>
>> the releasing branches. Less work would fall to the RMs tending the release
>>
>> branches if a common troublesome commit can be caught upstream first. In
>>
>> particular I am thinking about branch-1.
>>
>>
>>
>> I would like to volunteer to become the new RM for branch-1, to test and
>>
>> refine my above proposal in practice. Unless I hear objections I will
>>
>> assume by lazy consensus everyone is ok with this experiment.
>>
>>
>>
>> What this would mean:
>>
>>
>>
>> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner, and
>>
>> more likely with fix patches
>>
>> - Semiregular performance reports on branch-1 code as of date X/Y/Z, can
>>
>> compare with earlier reports for trending
>>
>> - Occasional sweep through master history looking for appropriate
>>
>> candidates for backport to branch-1, execution of said backport
>>
>> - Occasional 1B row ITBLL torture tests, probably if failure with bisect
>>
>> back to commit that introduced instability
>>
>>
>>
>> What this does not mean:
>>
>>
>>
>> - The branch-1 RM will not attempt to tell other branch RMs what or what
>>
>> not to include in their release branches
>>
>> - The branch-1 RM won't commit anything backported from master to any of
>>
>> the release branches; it will continue to be up to the release branch
>> RMs
>>
>> what they would or would not like to be included
>>
>>
>>
>> Also, I don't see why I couldn't spend some time looking at master now and
>>
>> then.
>>
>>
>>
>> I am going to assume our current co-RM team for branch-2 would maybe do
>>
>> something similar for branch-2, once it materializes.
>>
>>
>>
>> Thoughts? Comments? Concerns?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Best regards,
>>
>>
>>
>> - Andy
>>
>>
>>
>> If you are given a choice, you believe you have acted freely. - Raymond
>>
>> Teller (via Peter Watts)
>>
>>
Re: Proposal: Create "branch RM" roles for non releasing branches
branch-1, branch-2 (when it exists), and master
Posted by Nick Dimiduk <nd...@gmail.com>.
Somewhat late to the reply --
Does it make sense, for branch-1, to have the person planning to RM the
next minor release act as the RM for the major-level branch? That person
would hand responsibility to the next minor RM upon cutting the
stabilization branch.
This could be applied to master/branch-2 as well, but the further away we
get from a target release date, the more nebulous the RM role becomes.
On Fri, Jan 6, 2017 at 5:07 PM Andrew Purtell <ap...@apache.org> wrote:
> HBasers,
>
>
>
> I would like to propose extending our informal "branch RM" concept just a
>
> bit to include the nonreleasing branches like branch-1, branch-2 (when it
>
> exists), and master. These branches are where all commits are made passing
>
> through down to the releasing branches targeted for the change (like,
>
> branch-1.1, branch-1.2, branch-1.3, etc.)
>
>
>
> The releasing branches all have their own RM. I assume that RM is
>
> diligently monitoring its state, by way of review of commit history,
>
> occasional execution of the unit test suite, occasional execution of the
>
> integration tests, and has perhaps some automation in place to help with
>
> that on a nightly or weekly basis. No matter, let's assume there is a
>
> nonzero level of scrutiny applied to them, which leads to feedback to
>
> committers about inappropriate commits via compat guidelines, commits which
>
> have broken unit tests, or other indications of quality or functional
>
> concerns. I think it would improve our overall velocity as a project if we
>
> could also have volunteers tending the development branches upstream from
>
> the releasing branches. Less work would fall to the RMs tending the release
>
> branches if a common troublesome commit can be caught upstream first. In
>
> particular I am thinking about branch-1.
>
>
>
> I would like to volunteer to become the new RM for branch-1, to test and
>
> refine my above proposal in practice. Unless I hear objections I will
>
> assume by lazy consensus everyone is ok with this experiment.
>
>
>
> What this would mean:
>
>
>
> - JIRAs like "TestFooBar is broken on branch-1" will show up sooner, and
>
> more likely with fix patches
>
> - Semiregular performance reports on branch-1 code as of date X/Y/Z, can
>
> compare with earlier reports for trending
>
> - Occasional sweep through master history looking for appropriate
>
> candidates for backport to branch-1, execution of said backport
>
> - Occasional 1B row ITBLL torture tests, probably if failure with bisect
>
> back to commit that introduced instability
>
>
>
> What this does not mean:
>
>
>
> - The branch-1 RM will not attempt to tell other branch RMs what or what
>
> not to include in their release branches
>
> - The branch-1 RM won't commit anything backported from master to any of
>
> the release branches; it will continue to be up to the release branch
> RMs
>
> what they would or would not like to be included
>
>
>
> Also, I don't see why I couldn't spend some time looking at master now and
>
> then.
>
>
>
> I am going to assume our current co-RM team for branch-2 would maybe do
>
> something similar for branch-2, once it materializes.
>
>
>
> Thoughts? Comments? Concerns?
>
>
>
>
>
>
>
>
>
> --
>
> Best regards,
>
>
>
> - Andy
>
>
>
> If you are given a choice, you believe you have acted freely. - Raymond
>
> Teller (via Peter Watts)
>
>