Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Duo Zhang]

For the number of patch release, I think it depends on the speed we add new
features. The more features contained in a minor release, the more patch
releases we need. Of course a responsible RM will also trigger more
releases.

What I want to say is, we do not need to set a hard limit on the interval
between patch releases which may spend too much time for the RM, or force
users to upgrade to a new minor version because we will not make new patch
release for a previous minor version even it contains several critical bugs
since minor release could still break things according to our compatible
matrix. Just release on demand. I believe for the coming 2.0 and 2.1
release line, we will have (kinda) lots of fixes even after the final minor
release since there are lots of new features. It will be strange that we
just release a (kinda) buggy version and then tell users we will not fix it
any more, just upgrade to new minor versions...

And I think making releases should be part of the work of all PMCs.
Honestly say I'm not doing well in this area, and so do lots of others
PMCs. Will try to take more responsibility in the future.

Thanks.

2018-03-09 1:30 GMT+08:00 Andrew Purtell :

> The Phoenix project typically releases new minors. Patch releases are
> rare. This used to be our model too before 1.0. (For the 0.x.y versions
> mentally drop the "0.")
>
> Users don't seem to care.
>
> I do think there is appetite for one or two long term stable code lines.
> Right now that's branch-1.2. As long as we have an interested and engaged
> RM making regular releases we can give their work the LTS designation. When
> they move on more move up, we reevaluate.
>
> > From logistic perspective, we are moving from a model where few people
> are locked in for long time (4-5 RMs locked in for ~10 patch releases) to a
> model where more people are locked in for less time (more minor releases ->
> more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care takers).
>
> Yes, that's the idea.
>
> As branch-1 RM I would probably make new minor releases myself every 3-6
> months if we didn't have other volunteers. The period between minors will
> get longer as development activity slows and more activity moves to 2.0 and
> up. Unless we had a volunteer maintaining a minor branch they would be
> effectively retired once the new minor came out and had one or two patch
> releases, maybe, to fine tune.
>
>
> > On Mar 8, 2018, at 3:03 AM, Apekshit Sharma  wrote:
> >
> > So to sum up my understanding of the idea:
> > - More minor/major releases, less patch releases
> > - From logistic perspective, we are moving from a model where few people
> > are locked in for long time (4-5 RMs locked in for ~10 patch releases)
> to a
> > model where more people are locked in for less time (more minor releases
> ->
> > more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care
> takers).
> >
> > Just trying to put some numbers to make sure all are on same page.
> >
> > We can try it. Idea sounds good to me.
> >
> > @andrew: Is there any other community which follows this/similar pattern?
> > How's their experience? Do users like/hate more minor releases?
> >
> > -- Appy
> >
> >
> > On Thu, Mar 8, 2018 at 8:02 AM, Andrew Purtell 
> wrote:
> >
> >>>
> >> ​
> >> For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0
> >>
> >> Not as I originally proposed. In this example, Andrew will caretake
> >> branch-1 and Stack will caretake branch-2.  Andrew and Stack will be
> making
> >> more minor release branches more often and patch releases will become
> less
> >> frequent. For example, I'm going to be done with branch-1.4 in six
> months
> >> and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those
> >> branch-x.y. As long as someone is actively RMing branch-x.y it stays
> alive.
> >> That's how we'd come to a consensus on what is long term stable.
> >>
> >>
> >>> On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma 
> wrote:
> >>>
> >>> I like the thought, continuing to brainstorm
> >>> In this method, the following holds true, right?
> >>> - Care taking "branch-X.Y" will require least effort and will by
> default
> >>> fall onto the shoulders of RM for X.Y version.
> >>> ​​
> >>> For eg. Andrew will caretake
> >>> branch-1.4, Stack will caretake branch-2.0, and so on.
> >>> - Care taking "branch-X" will require a bit more effort and it's
> >> uncertain
> >>> how to assign one to such branches.
> >>>  One way is, whoever will do the next minor release can own it. But the
> >>> caveat in that is,
> >>>  a) It's hard to find RMs as such, this may make it more difficult
> since
> >>> one will have to own up the task much ahead in advance. Or, the effect
> >>> could be opposite, since this way gives more heads up for carrying out
> RM
> >>> responsibilities. Would be certainly interesting to see how it works
> out.
> >>>  b) For 

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Andrew Purtell]

The Phoenix project typically releases new minors. Patch releases are rare. 
This used to be our model too before 1.0. (For the 0.x.y versions mentally drop 
the "0.")

Users don't seem to care. 

I do think there is appetite for one or two long term stable code lines. Right 
now that's branch-1.2. As long as we have an interested and engaged RM making 
regular releases we can give their work the LTS designation. When they move on 
more move up, we reevaluate. 

> From logistic perspective, we are moving from a model where few people are 
> locked in for long time (4-5 RMs locked in for ~10 patch releases) to a model 
> where more people are locked in for less time (more minor releases -> more 
> RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care takers).

Yes, that's the idea. 

As branch-1 RM I would probably make new minor releases myself every 3-6 months 
if we didn't have other volunteers. The period between minors will get longer 
as development activity slows and more activity moves to 2.0 and up. Unless we 
had a volunteer maintaining a minor branch they would be effectively retired 
once the new minor came out and had one or two patch releases, maybe, to fine 
tune. 


> On Mar 8, 2018, at 3:03 AM, Apekshit Sharma  wrote:
> 
> So to sum up my understanding of the idea:
> - More minor/major releases, less patch releases
> - From logistic perspective, we are moving from a model where few people
> are locked in for long time (4-5 RMs locked in for ~10 patch releases) to a
> model where more people are locked in for less time (more minor releases ->
> more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care takers).
> 
> Just trying to put some numbers to make sure all are on same page.
> 
> We can try it. Idea sounds good to me.
> 
> @andrew: Is there any other community which follows this/similar pattern?
> How's their experience? Do users like/hate more minor releases?
> 
> -- Appy
> 
> 
> On Thu, Mar 8, 2018 at 8:02 AM, Andrew Purtell  wrote:
> 
>>> 
>> ​
>> For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0
>> 
>> Not as I originally proposed. In this example, Andrew will caretake
>> branch-1 and Stack will caretake branch-2.  Andrew and Stack will be making
>> more minor release branches more often and patch releases will become less
>> frequent. For example, I'm going to be done with branch-1.4 in six months
>> and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those
>> branch-x.y. As long as someone is actively RMing branch-x.y it stays alive.
>> That's how we'd come to a consensus on what is long term stable.
>> 
>> 
>>> On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma  wrote:
>>> 
>>> I like the thought, continuing to brainstorm
>>> In this method, the following holds true, right?
>>> - Care taking "branch-X.Y" will require least effort and will by default
>>> fall onto the shoulders of RM for X.Y version.
>>> ​​
>>> For eg. Andrew will caretake
>>> branch-1.4, Stack will caretake branch-2.0, and so on.
>>> - Care taking "branch-X" will require a bit more effort and it's
>> uncertain
>>> how to assign one to such branches.
>>>  One way is, whoever will do the next minor release can own it. But the
>>> caveat in that is,
>>>  a) It's hard to find RMs as such, this may make it more difficult since
>>> one will have to own up the task much ahead in advance. Or, the effect
>>> could be opposite, since this way gives more heads up for carrying out RM
>>> responsibilities. Would be certainly interesting to see how it works out.
>>>  b) For branch-1 which might be close to finish, there's uncertainty -
>>> assign care taker but no future release (wasted effort?), OR, no care
>> taker
>>> until we decide that there will be future release (more like status
>>> quo). We can make the decision when we are at the fork. For now, seems
>> like
>>> we have one who's willing to take care of branch-1 to shepherd it towards
>>> 1.5.0smile.
>>> 
>>>  Other way is, once can just caretake a branch without singing up to do
>>> the next release.
>>>  I don't think we have to choose one way or another (in fact, we might
>> not
>>> have the luxury) and instead, can go with the flow (i.e. as contributions
>>> show up).
>>> 
>>> - Care taking for "master": The most onerous task since almost everything
>>> goes in it - all patches, new features, bug fixes, test breaking changes,
>>> etc.  Defining 'care taking' of this branch will be a bit more difficult.
>>> Might be too big for single person, maybe round robin the task among
>>> committers/contributors (generates another opportunity for contributors
>> to
>>> sparkle and become committers)?
>>> Unless this one is solved, we are not rectifying the problem mentioned by
>>> Stack previously - "...avoiding the hell that was 2.0.0 where its taken
>>> near on a year to stabilize (first alpha was last year) because it has
>> over
>>> 5k JIRAs in it".
>>> 

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Chia-Ping Tsai]

> frequent. For example, I'm going to be done with branch-1.4 in six months
> and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those
> branch-x.y. As long as someone is actively RMing branch-x.y it stays alive.
> That's how we'd come to a consensus on what is long term stable.
I love the idea! The previous release schedule exhausts RMs and increase 
fragmentation of HBase. 

So if no other people try to RM the MINOR release, the following will come true
1) no PATCH release
2) a MINOR release per 6 months
3) a MAJOR release per 2.5 years (6 months * 5 minor releases, it means we 
release 3.0 and 2.4/2.5 at the same time)
In this scenario, 3 branch RMs manage our all releases. (branch-1, branch-2, 
and master)

If someone(PMC, committer, or ?) want to RM the minor release(Only latest minor 
release can be RM? Or we can active any retired MINOR release?)
1) a patch release per 2 week (6 months / 10 patch releases, or issue-trigger?)


On 2018/03/08 02:32:24, Andrew Purtell  wrote: 
> >
> ​
> For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0
> 
> Not as I originally proposed. In this example, Andrew will caretake
> branch-1 and Stack will caretake branch-2.  Andrew and Stack will be making
> more minor release branches more often and patch releases will become less
> frequent. For example, I'm going to be done with branch-1.4 in six months
> and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those
> branch-x.y. As long as someone is actively RMing branch-x.y it stays alive.
> That's how we'd come to a consensus on what is long term stable.
> 
> 
> On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma  wrote:
> 
> > I like the thought, continuing to brainstorm
> > In this method, the following holds true, right?
> > - Care taking "branch-X.Y" will require least effort and will by default
> > fall onto the shoulders of RM for X.Y version.
> > ​​
> > For eg. Andrew will caretake
> > branch-1.4, Stack will caretake branch-2.0, and so on.
> > - Care taking "branch-X" will require a bit more effort and it's uncertain
> > how to assign one to such branches.
> >   One way is, whoever will do the next minor release can own it. But the
> > caveat in that is,
> >   a) It's hard to find RMs as such, this may make it more difficult since
> > one will have to own up the task much ahead in advance. Or, the effect
> > could be opposite, since this way gives more heads up for carrying out RM
> > responsibilities. Would be certainly interesting to see how it works out.
> >   b) For branch-1 which might be close to finish, there's uncertainty -
> > assign care taker but no future release (wasted effort?), OR, no care taker
> > until we decide that there will be future release (more like status
> > quo). We can make the decision when we are at the fork. For now, seems like
> > we have one who's willing to take care of branch-1 to shepherd it towards
> > 1.5.0smile.
> >
> >   Other way is, once can just caretake a branch without singing up to do
> > the next release.
> >   I don't think we have to choose one way or another (in fact, we might not
> > have the luxury) and instead, can go with the flow (i.e. as contributions
> > show up).
> >
> > - Care taking for "master": The most onerous task since almost everything
> > goes in it - all patches, new features, bug fixes, test breaking changes,
> > etc.  Defining 'care taking' of this branch will be a bit more difficult.
> > Might be too big for single person, maybe round robin the task among
> > committers/contributors (generates another opportunity for contributors to
> > sparkle and become committers)?
> > Unless this one is solved, we are not rectifying the problem mentioned by
> > Stack previously - "...avoiding the hell that was 2.0.0 where its taken
> > near on a year to stabilize (first alpha was last year) because it has over
> > 5k JIRAs in it".
> >
> > To end on positive note, i volunteer to care take branch-2 once 2.0 GA is
> > out.
> >
> > -- Appy
> >
> > On Thu, Mar 8, 2018 at 6:10 AM, Mike Drob  wrote:
> >
> > > If somebody volunteers to be the caretaker for 1.5.0, is there an
> > implicit
> > > expectation that they would take on the responsibilities for branch-1 as
> > > well?
> > >
> > > On Wed, Mar 7, 2018 at 5:12 PM, Stack  wrote:
> > >
> > > > (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
> > > > from..." -- my fault for starting it in wrong place)
> > > >
> > > > A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like this
> > > > suggestion. I see it as a means of avoiding the hell that was 2.0.0
> > where
> > > > its taken near on a year to stabilize (first alpha was last year)
> > because
> > > > it has over 5k JIRAs in it; RMs can help keep their branch tidy and
> > free
> > > of
> > > > flotsam.
> > > >
> > > > Andrew added more to his notion of 'branch RM' over in the NOTICE
> > > thread. 

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Apekshit Sharma]

So to sum up my understanding of the idea:
- More minor/major releases, less patch releases
- From logistic perspective, we are moving from a model where few people
are locked in for long time (4-5 RMs locked in for ~10 patch releases) to a
model where more people are locked in for less time (more minor releases ->
more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care takers).

Just trying to put some numbers to make sure all are on same page.

We can try it. Idea sounds good to me.

@andrew: Is there any other community which follows this/similar pattern?
How's their experience? Do users like/hate more minor releases?

-- Appy


On Thu, Mar 8, 2018 at 8:02 AM, Andrew Purtell  wrote:

> >
> ​
> For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0
>
> Not as I originally proposed. In this example, Andrew will caretake
> branch-1 and Stack will caretake branch-2.  Andrew and Stack will be making
> more minor release branches more often and patch releases will become less
> frequent. For example, I'm going to be done with branch-1.4 in six months
> and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those
> branch-x.y. As long as someone is actively RMing branch-x.y it stays alive.
> That's how we'd come to a consensus on what is long term stable.
>
>
> On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma  wrote:
>
> > I like the thought, continuing to brainstorm
> > In this method, the following holds true, right?
> > - Care taking "branch-X.Y" will require least effort and will by default
> > fall onto the shoulders of RM for X.Y version.
> > ​​
> > For eg. Andrew will caretake
> > branch-1.4, Stack will caretake branch-2.0, and so on.
> > - Care taking "branch-X" will require a bit more effort and it's
> uncertain
> > how to assign one to such branches.
> >   One way is, whoever will do the next minor release can own it. But the
> > caveat in that is,
> >   a) It's hard to find RMs as such, this may make it more difficult since
> > one will have to own up the task much ahead in advance. Or, the effect
> > could be opposite, since this way gives more heads up for carrying out RM
> > responsibilities. Would be certainly interesting to see how it works out.
> >   b) For branch-1 which might be close to finish, there's uncertainty -
> > assign care taker but no future release (wasted effort?), OR, no care
> taker
> > until we decide that there will be future release (more like status
> > quo). We can make the decision when we are at the fork. For now, seems
> like
> > we have one who's willing to take care of branch-1 to shepherd it towards
> > 1.5.0smile.
> >
> >   Other way is, once can just caretake a branch without singing up to do
> > the next release.
> >   I don't think we have to choose one way or another (in fact, we might
> not
> > have the luxury) and instead, can go with the flow (i.e. as contributions
> > show up).
> >
> > - Care taking for "master": The most onerous task since almost everything
> > goes in it - all patches, new features, bug fixes, test breaking changes,
> > etc.  Defining 'care taking' of this branch will be a bit more difficult.
> > Might be too big for single person, maybe round robin the task among
> > committers/contributors (generates another opportunity for contributors
> to
> > sparkle and become committers)?
> > Unless this one is solved, we are not rectifying the problem mentioned by
> > Stack previously - "...avoiding the hell that was 2.0.0 where its taken
> > near on a year to stabilize (first alpha was last year) because it has
> over
> > 5k JIRAs in it".
> >
> > To end on positive note, i volunteer to care take branch-2 once 2.0 GA is
> > out.
> >
> > -- Appy
> >
> > On Thu, Mar 8, 2018 at 6:10 AM, Mike Drob  wrote:
> >
> > > If somebody volunteers to be the caretaker for 1.5.0, is there an
> > implicit
> > > expectation that they would take on the responsibilities for branch-1
> as
> > > well?
> > >
> > > On Wed, Mar 7, 2018 at 5:12 PM, Stack  wrote:
> > >
> > > > (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
> > > > from..." -- my fault for starting it in wrong place)
> > > >
> > > > A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like
> this
> > > > suggestion. I see it as a means of avoiding the hell that was 2.0.0
> > where
> > > > its taken near on a year to stabilize (first alpha was last year)
> > because
> > > > it has over 5k JIRAs in it; RMs can help keep their branch tidy and
> > free
> > > of
> > > > flotsam.
> > > >
> > > > Andrew added more to his notion of 'branch RM' over in the NOTICE
> > > thread. I
> > > > repeat it below:
> > > >
> > > > "​For a while leading up to 1.4.0 I was effectively the branch-1 RM
> in
> > > > practice. Slacked off a bit since, but I'd like to continue with that
> > if
> > > > you're agreeable. I think that branch RM role involves informally:
> > > > - Keeping an 

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Andrew Purtell]

>
​
For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0

Not as I originally proposed. In this example, Andrew will caretake
branch-1 and Stack will caretake branch-2.  Andrew and Stack will be making
more minor release branches more often and patch releases will become less
frequent. For example, I'm going to be done with branch-1.4 in six months
and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those
branch-x.y. As long as someone is actively RMing branch-x.y it stays alive.
That's how we'd come to a consensus on what is long term stable.


On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma  wrote:

> I like the thought, continuing to brainstorm
> In this method, the following holds true, right?
> - Care taking "branch-X.Y" will require least effort and will by default
> fall onto the shoulders of RM for X.Y version.
> ​​
> For eg. Andrew will caretake
> branch-1.4, Stack will caretake branch-2.0, and so on.
> - Care taking "branch-X" will require a bit more effort and it's uncertain
> how to assign one to such branches.
>   One way is, whoever will do the next minor release can own it. But the
> caveat in that is,
>   a) It's hard to find RMs as such, this may make it more difficult since
> one will have to own up the task much ahead in advance. Or, the effect
> could be opposite, since this way gives more heads up for carrying out RM
> responsibilities. Would be certainly interesting to see how it works out.
>   b) For branch-1 which might be close to finish, there's uncertainty -
> assign care taker but no future release (wasted effort?), OR, no care taker
> until we decide that there will be future release (more like status
> quo). We can make the decision when we are at the fork. For now, seems like
> we have one who's willing to take care of branch-1 to shepherd it towards
> 1.5.0smile.
>
>   Other way is, once can just caretake a branch without singing up to do
> the next release.
>   I don't think we have to choose one way or another (in fact, we might not
> have the luxury) and instead, can go with the flow (i.e. as contributions
> show up).
>
> - Care taking for "master": The most onerous task since almost everything
> goes in it - all patches, new features, bug fixes, test breaking changes,
> etc.  Defining 'care taking' of this branch will be a bit more difficult.
> Might be too big for single person, maybe round robin the task among
> committers/contributors (generates another opportunity for contributors to
> sparkle and become committers)?
> Unless this one is solved, we are not rectifying the problem mentioned by
> Stack previously - "...avoiding the hell that was 2.0.0 where its taken
> near on a year to stabilize (first alpha was last year) because it has over
> 5k JIRAs in it".
>
> To end on positive note, i volunteer to care take branch-2 once 2.0 GA is
> out.
>
> -- Appy
>
> On Thu, Mar 8, 2018 at 6:10 AM, Mike Drob  wrote:
>
> > If somebody volunteers to be the caretaker for 1.5.0, is there an
> implicit
> > expectation that they would take on the responsibilities for branch-1 as
> > well?
> >
> > On Wed, Mar 7, 2018 at 5:12 PM, Stack  wrote:
> >
> > > (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
> > > from..." -- my fault for starting it in wrong place)
> > >
> > > A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like this
> > > suggestion. I see it as a means of avoiding the hell that was 2.0.0
> where
> > > its taken near on a year to stabilize (first alpha was last year)
> because
> > > it has over 5k JIRAs in it; RMs can help keep their branch tidy and
> free
> > of
> > > flotsam.
> > >
> > > Andrew added more to his notion of 'branch RM' over in the NOTICE
> > thread. I
> > > repeat it below:
> > >
> > > "​For a while leading up to 1.4.0 I was effectively the branch-1 RM in
> > > practice. Slacked off a bit since, but I'd like to continue with that
> if
> > > you're agreeable. I think that branch RM role involves informally:
> > > - Keeping an eye on commits to branch. Periodic review of recent
> commits.
> > > Not acting as a gate on commits and not needing to be pinged or in the
> > loop
> > > for every commit, except perhaps for short periods of time around
> > branching
> > > for new minors.
> > > - Keeping an eye on test stability. Undertaking get well projects like
> > > bisecting and reverting offending commits to resolve test suite decay.
> > > - Periodically kicking off new minor releases. Depends on branch and
> need
> > > for what's on deck."
> > >
> > > Interested in what folks think.
> > > St.Ack
> > >
> > > 1. *https://lists.apache.org/thread.html/
> 247697bcfb97adeeec2d14241856ca
> > > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E
> > >  > > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E>*
> > >
> >
>
>
>
> --
>
> -- Appy
>



-- 
Best regards,

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Andrew Purtell]

> If somebody volunteers to be the caretaker for 1.5.0, is there an
implicit expectation that they would take on the responsibilities for
branch-1 as well?

Not as I originally proposed.

We will get away from RMs per branch for e.g. branch-1.y and focus on RMs
for each branch-x (and master). We are wasting precious RM effort on
branches that only produce patch releases. We should be focusing this
limited attention on branches that produce minor releases, and increase the
cadence of minor releases. This does not preclude maintenance of "long term
stable" patch release branches, like branch-1.2.


On Wed, Mar 7, 2018 at 4:40 PM, Mike Drob  wrote:

> If somebody volunteers to be the caretaker for 1.5.0, is there an implicit
> expectation that they would take on the responsibilities for branch-1 as
> well?
>
> On Wed, Mar 7, 2018 at 5:12 PM, Stack  wrote:
>
> > (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
> > from..." -- my fault for starting it in wrong place)
> >
> > A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like this
> > suggestion. I see it as a means of avoiding the hell that was 2.0.0 where
> > its taken near on a year to stabilize (first alpha was last year) because
> > it has over 5k JIRAs in it; RMs can help keep their branch tidy and free
> of
> > flotsam.
> >
> > Andrew added more to his notion of 'branch RM' over in the NOTICE
> thread. I
> > repeat it below:
> >
> > "​For a while leading up to 1.4.0 I was effectively the branch-1 RM in
> > practice. Slacked off a bit since, but I'd like to continue with that if
> > you're agreeable. I think that branch RM role involves informally:
> > - Keeping an eye on commits to branch. Periodic review of recent commits.
> > Not acting as a gate on commits and not needing to be pinged or in the
> loop
> > for every commit, except perhaps for short periods of time around
> branching
> > for new minors.
> > - Keeping an eye on test stability. Undertaking get well projects like
> > bisecting and reverting offending commits to resolve test suite decay.
> > - Periodically kicking off new minor releases. Depends on branch and need
> > for what's on deck."
> >
> > Interested in what folks think.
> > St.Ack
> >
> > 1. *https://lists.apache.org/thread.html/247697bcfb97adeeec2d14241856ca
> > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E
> >  > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E>*
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Apekshit Sharma]

I like the thought, continuing to brainstorm
In this method, the following holds true, right?
- Care taking "branch-X.Y" will require least effort and will by default
fall onto the shoulders of RM for X.Y version. For eg. Andrew will caretake
branch-1.4, Stack will caretake branch-2.0, and so on.
- Care taking "branch-X" will require a bit more effort and it's uncertain
how to assign one to such branches.
  One way is, whoever will do the next minor release can own it. But the
caveat in that is,
  a) It's hard to find RMs as such, this may make it more difficult since
one will have to own up the task much ahead in advance. Or, the effect
could be opposite, since this way gives more heads up for carrying out RM
responsibilities. Would be certainly interesting to see how it works out.
  b) For branch-1 which might be close to finish, there's uncertainty -
assign care taker but no future release (wasted effort?), OR, no care taker
until we decide that there will be future release (more like status
quo). We can make the decision when we are at the fork. For now, seems like
we have one who's willing to take care of branch-1 to shepherd it towards
1.5.0smile.

  Other way is, once can just caretake a branch without singing up to do
the next release.
  I don't think we have to choose one way or another (in fact, we might not
have the luxury) and instead, can go with the flow (i.e. as contributions
show up).

- Care taking for "master": The most onerous task since almost everything
goes in it - all patches, new features, bug fixes, test breaking changes,
etc.  Defining 'care taking' of this branch will be a bit more difficult.
Might be too big for single person, maybe round robin the task among
committers/contributors (generates another opportunity for contributors to
sparkle and become committers)?
Unless this one is solved, we are not rectifying the problem mentioned by
Stack previously - "...avoiding the hell that was 2.0.0 where its taken
near on a year to stabilize (first alpha was last year) because it has over
5k JIRAs in it".

To end on positive note, i volunteer to care take branch-2 once 2.0 GA is
out.

-- Appy

On Thu, Mar 8, 2018 at 6:10 AM, Mike Drob  wrote:

> If somebody volunteers to be the caretaker for 1.5.0, is there an implicit
> expectation that they would take on the responsibilities for branch-1 as
> well?
>
> On Wed, Mar 7, 2018 at 5:12 PM, Stack  wrote:
>
> > (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
> > from..." -- my fault for starting it in wrong place)
> >
> > A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like this
> > suggestion. I see it as a means of avoiding the hell that was 2.0.0 where
> > its taken near on a year to stabilize (first alpha was last year) because
> > it has over 5k JIRAs in it; RMs can help keep their branch tidy and free
> of
> > flotsam.
> >
> > Andrew added more to his notion of 'branch RM' over in the NOTICE
> thread. I
> > repeat it below:
> >
> > "​For a while leading up to 1.4.0 I was effectively the branch-1 RM in
> > practice. Slacked off a bit since, but I'd like to continue with that if
> > you're agreeable. I think that branch RM role involves informally:
> > - Keeping an eye on commits to branch. Periodic review of recent commits.
> > Not acting as a gate on commits and not needing to be pinged or in the
> loop
> > for every commit, except perhaps for short periods of time around
> branching
> > for new minors.
> > - Keeping an eye on test stability. Undertaking get well projects like
> > bisecting and reverting offending commits to resolve test suite decay.
> > - Periodically kicking off new minor releases. Depends on branch and need
> > for what's on deck."
> >
> > Interested in what folks think.
> > St.Ack
> >
> > 1. *https://lists.apache.org/thread.html/247697bcfb97adeeec2d14241856ca
> > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E
> >  > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E>*
> >
>



-- 

-- Appy

Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Mike Drob]

If somebody volunteers to be the caretaker for 1.5.0, is there an implicit
expectation that they would take on the responsibilities for branch-1 as
well?

On Wed, Mar 7, 2018 at 5:12 PM, Stack  wrote:

> (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
> from..." -- my fault for starting it in wrong place)
>
> A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like this
> suggestion. I see it as a means of avoiding the hell that was 2.0.0 where
> its taken near on a year to stabilize (first alpha was last year) because
> it has over 5k JIRAs in it; RMs can help keep their branch tidy and free of
> flotsam.
>
> Andrew added more to his notion of 'branch RM' over in the NOTICE thread. I
> repeat it below:
>
> "​For a while leading up to 1.4.0 I was effectively the branch-1 RM in
> practice. Slacked off a bit since, but I'd like to continue with that if
> you're agreeable. I think that branch RM role involves informally:
> - Keeping an eye on commits to branch. Periodic review of recent commits.
> Not acting as a gate on commits and not needing to be pinged or in the loop
> for every commit, except perhaps for short periods of time around branching
> for new minors.
> - Keeping an eye on test stability. Undertaking get well projects like
> bisecting and reverting offending commits to resolve test suite decay.
> - Periodically kicking off new minor releases. Depends on branch and need
> for what's on deck."
>
> Interested in what folks think.
> St.Ack
>
> 1. *https://lists.apache.org/thread.html/247697bcfb97adeeec2d14241856ca
> 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E
>  7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E>*
>

DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master

[Stack]

(Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0
from..." -- my fault for starting it in wrong place)

A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like this
suggestion. I see it as a means of avoiding the hell that was 2.0.0 where
its taken near on a year to stabilize (first alpha was last year) because
it has over 5k JIRAs in it; RMs can help keep their branch tidy and free of
flotsam.

Andrew added more to his notion of 'branch RM' over in the NOTICE thread. I
repeat it below:

"​For a while leading up to 1.4.0 I was effectively the branch-1 RM in
practice. Slacked off a bit since, but I'd like to continue with that if
you're agreeable. I think that branch RM role involves informally:
- Keeping an eye on commits to branch. Periodic review of recent commits.
Not acting as a gate on commits and not needing to be pinged or in the loop
for every commit, except perhaps for short periods of time around branching
for new minors.
- Keeping an eye on test stability. Undertaking get well projects like
bisecting and reverting offending commits to resolve test suite decay.
- Periodically kicking off new minor releases. Depends on branch and need
for what's on deck."

Interested in what folks think.
St.Ack

1. 
*https://lists.apache.org/thread.html/247697bcfb97adeeec2d14241856ca7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E
*