Re: Moving 2.0 forward

[Phil Yang <ud...@gmail.com>]

Hi all
After cutting branch-2, what will we do for branch-1? If I am not wrong,
1.4 may be the last 1.x release branch? Should 1.4.0 release before 2.0.0?
If not, will it confuse users?

Thanks,
Phil


2017-01-01 5:20 GMT+08:00 Andrew Purtell <an...@gmail.com>:

> On the other hand branching will force the issue. There will always be
> lists of issues to get in. How long have we been talking about 2.0? At
> least a year and a half. At some point it's time to stop talking and take
> action. Let me revisit progress at the end of January and bring this up
> again. As a member of the PMC I'm advising all concerned that 2.0 is
> talking too long and I am considering steps to move it forward.
>
>
> > On Dec 31, 2016, at 12:54 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> > I agree with Stephen on not branching too early.
> >
> > When people come back from vacation, we can poll relevant parties on
> > estimate of respective project to get a sense of when would be proper
> time
> > for branching.
> >
> > On Sat, Dec 31, 2016 at 12:16 PM, Stephen Jiang <syuanjiangdev@gmail.com
> >
> > wrote:
> >
> >> Hello, Andrew, I was a helper on Matteo so that we can help each other
> >> while we are focusing on the new Assignment Manager work.  Now he is not
> >> available (at least in the next few months).  I have to be more focused
> on
> >> the new AM work; plus other work in my company; it would be too much
> for me
> >> to 2.0 RM alone.  I am happy someone would help to take primary 2.0 RM
> role
> >> while I am still help to make this 2.0 release smooth.
> >>
> >> For branch-2, I think it is too early to cut it, as we still have a lot
> of
> >> moving parts and on-going project that needs to be part of 2.0.  For
> >> example, the mentioned new AM (and other projects, such as HBASE-14414,
> >> HBASE-15179, HBASE-14070, HBASE-14850, HBASE-16833, HBASE-15531, just
> name
> >> a few).  Cutting branch now would add burden to complete those projects.
> >>
> >> thanks
> >> Stephen
> >>
> >> On Sat, Dec 31, 2016 at 10:54 AM, Andrew Purtell <
> andrew.purtell@gmail.com
> >>>
> >> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I've heard a rumor the co-RM situation with 2.0 may have changed. Can
> we
> >>> get an update from co-RMs Matteo and Steven on their availability and
> >>> interest in continuing in this role?
> >>>
> >>> To assist in moving 2.0 forward I intend to branch branch-2 from master
> >>> next week. Unless there is an objection I will take this action under
> >>> assumption of lazy consensus. Master branch will be renumbered to
> >>> 3.0.0-SNAPSHOT. Once we have a branch-2 I will immediately begin scale
> >>> tests and stabilization (via bug fixes or reverts of unfinished work)
> and
> >>> invite interested collaborators to do the same.
> >>>
> >>>
> >>>
> >>
>

Re: Moving 2.0 forward

[Jerry He <je...@gmail.com>]

I agree we need a long and stable 1.x release. Branch-1 is a good fit for
that role.
It has the stability and compatibility of 1.x, and it has still been quite
open for flow of improvements and commits.

+1


Jerry

On Fri, Jan 6, 2017 at 1:01 PM, Mikhail Antonov <ol...@gmail.com>
wrote:

> I support that idea of cutting branch-2 early. Yes it will create some
> burden for the RM and committers to port things between the
> branches, but until the branch is cut we won't have that sense of imminense
> of approaching release, and more importantly, until
> branch is cut _all_ commits will continue to go there, making it hard to
> stabilize.
>
> Regarding branch-1 and branch-2 release lines, agree those are unrelated
> questions. I'm all for frequent and fast updates to new versions, but
> obviously we can't drop support and development on branch-1 until 2.0 is
> released and probed by early adopters, and then not until 2.0 is as stable
> as what people running late 1.* branches currently have.
>
> Thanks,
> Mikhail
>
> On Fri, Jan 6, 2017 at 10:40 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > Considerations for a new branch-2 and branch-1 are orthogonal in my
> > opinion.
> >
> > I intend to volunteer to be the RM for branch-1 itself (we've not had one
> > before) as necessary for it to become a stable source of incremental
> > releases for a long time, similar to how we had 0.98 active for almost
> > three years while 1.x development took place. Where I work we plan to
> have
> > branch-1 based code in production for at least one year, probably longer.
> >
> > Given the above arrangement, releases from branch-1 and branch-2 would
> > have independent roadmaps and release timelines.
> >
> > Does this sound reasonable?
> >
> >
> > > On Jan 5, 2017, at 11:51 PM, Phil Yang <ud...@gmail.com> wrote:
> > >
> > > Hi all
> > > After cutting branch-2, what will we do for branch-1? If I am not
> wrong,
> > > 1.4 may be the last 1.x release branch? Should 1.4.0 release before
> > 2.0.0?
> > > If not, will it confuse users?
> > >
> > > Thanks,
> > > Phil
> > >
> > >
> > > 2017-01-01 5:20 GMT+08:00 Andrew Purtell <an...@gmail.com>:
> > >
> > >> On the other hand branching will force the issue. There will always be
> > >> lists of issues to get in. How long have we been talking about 2.0? At
> > >> least a year and a half. At some point it's time to stop talking and
> > take
> > >> action. Let me revisit progress at the end of January and bring this
> up
> > >> again. As a member of the PMC I'm advising all concerned that 2.0 is
> > >> talking too long and I am considering steps to move it forward.
> > >>
> > >>
> > >>> On Dec 31, 2016, at 12:54 PM, Ted Yu <yu...@gmail.com> wrote:
> > >>>
> > >>> I agree with Stephen on not branching too early.
> > >>>
> > >>> When people come back from vacation, we can poll relevant parties on
> > >>> estimate of respective project to get a sense of when would be proper
> > >> time
> > >>> for branching.
> > >>>
> > >>> On Sat, Dec 31, 2016 at 12:16 PM, Stephen Jiang <
> > syuanjiangdev@gmail.com
> > >>>
> > >>> wrote:
> > >>>
> > >>>> Hello, Andrew, I was a helper on Matteo so that we can help each
> other
> > >>>> while we are focusing on the new Assignment Manager work.  Now he is
> > not
> > >>>> available (at least in the next few months).  I have to be more
> > focused
> > >> on
> > >>>> the new AM work; plus other work in my company; it would be too much
> > >> for me
> > >>>> to 2.0 RM alone.  I am happy someone would help to take primary 2.0
> RM
> > >> role
> > >>>> while I am still help to make this 2.0 release smooth.
> > >>>>
> > >>>> For branch-2, I think it is too early to cut it, as we still have a
> > lot
> > >> of
> > >>>> moving parts and on-going project that needs to be part of 2.0.  For
> > >>>> example, the mentioned new AM (and other projects, such as
> > HBASE-14414,
> > >>>> HBASE-15179, HBASE-14070, HBASE-14850, HBASE-16833, HBASE-15531,
> just
> > >> name
> > >>>> a few).  Cutting branch now would add burden to complete those
> > projects.
> > >>>>
> > >>>> thanks
> > >>>> Stephen
> > >>>>
> > >>>> On Sat, Dec 31, 2016 at 10:54 AM, Andrew Purtell <
> > >> andrew.purtell@gmail.com
> > >>>>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi all,
> > >>>>>
> > >>>>> I've heard a rumor the co-RM situation with 2.0 may have changed.
> Can
> > >> we
> > >>>>> get an update from co-RMs Matteo and Steven on their availability
> and
> > >>>>> interest in continuing in this role?
> > >>>>>
> > >>>>> To assist in moving 2.0 forward I intend to branch branch-2 from
> > master
> > >>>>> next week. Unless there is an objection I will take this action
> under
> > >>>>> assumption of lazy consensus. Master branch will be renumbered to
> > >>>>> 3.0.0-SNAPSHOT. Once we have a branch-2 I will immediately begin
> > scale
> > >>>>> tests and stabilization (via bug fixes or reverts of unfinished
> work)
> > >> and
> > >>>>> invite interested collaborators to do the same.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>

Re: Moving 2.0 forward

[Mikhail Antonov <ol...@gmail.com>]

I support that idea of cutting branch-2 early. Yes it will create some
burden for the RM and committers to port things between the
branches, but until the branch is cut we won't have that sense of imminense
of approaching release, and more importantly, until
branch is cut _all_ commits will continue to go there, making it hard to
stabilize.

Regarding branch-1 and branch-2 release lines, agree those are unrelated
questions. I'm all for frequent and fast updates to new versions, but
obviously we can't drop support and development on branch-1 until 2.0 is
released and probed by early adopters, and then not until 2.0 is as stable
as what people running late 1.* branches currently have.

Thanks,
Mikhail

On Fri, Jan 6, 2017 at 10:40 AM, Andrew Purtell <an...@gmail.com>
wrote:

> Considerations for a new branch-2 and branch-1 are orthogonal in my
> opinion.
>
> I intend to volunteer to be the RM for branch-1 itself (we've not had one
> before) as necessary for it to become a stable source of incremental
> releases for a long time, similar to how we had 0.98 active for almost
> three years while 1.x development took place. Where I work we plan to have
> branch-1 based code in production for at least one year, probably longer.
>
> Given the above arrangement, releases from branch-1 and branch-2 would
> have independent roadmaps and release timelines.
>
> Does this sound reasonable?
>
>
> > On Jan 5, 2017, at 11:51 PM, Phil Yang <ud...@gmail.com> wrote:
> >
> > Hi all
> > After cutting branch-2, what will we do for branch-1? If I am not wrong,
> > 1.4 may be the last 1.x release branch? Should 1.4.0 release before
> 2.0.0?
> > If not, will it confuse users?
> >
> > Thanks,
> > Phil
> >
> >
> > 2017-01-01 5:20 GMT+08:00 Andrew Purtell <an...@gmail.com>:
> >
> >> On the other hand branching will force the issue. There will always be
> >> lists of issues to get in. How long have we been talking about 2.0? At
> >> least a year and a half. At some point it's time to stop talking and
> take
> >> action. Let me revisit progress at the end of January and bring this up
> >> again. As a member of the PMC I'm advising all concerned that 2.0 is
> >> talking too long and I am considering steps to move it forward.
> >>
> >>
> >>> On Dec 31, 2016, at 12:54 PM, Ted Yu <yu...@gmail.com> wrote:
> >>>
> >>> I agree with Stephen on not branching too early.
> >>>
> >>> When people come back from vacation, we can poll relevant parties on
> >>> estimate of respective project to get a sense of when would be proper
> >> time
> >>> for branching.
> >>>
> >>> On Sat, Dec 31, 2016 at 12:16 PM, Stephen Jiang <
> syuanjiangdev@gmail.com
> >>>
> >>> wrote:
> >>>
> >>>> Hello, Andrew, I was a helper on Matteo so that we can help each other
> >>>> while we are focusing on the new Assignment Manager work.  Now he is
> not
> >>>> available (at least in the next few months).  I have to be more
> focused
> >> on
> >>>> the new AM work; plus other work in my company; it would be too much
> >> for me
> >>>> to 2.0 RM alone.  I am happy someone would help to take primary 2.0 RM
> >> role
> >>>> while I am still help to make this 2.0 release smooth.
> >>>>
> >>>> For branch-2, I think it is too early to cut it, as we still have a
> lot
> >> of
> >>>> moving parts and on-going project that needs to be part of 2.0.  For
> >>>> example, the mentioned new AM (and other projects, such as
> HBASE-14414,
> >>>> HBASE-15179, HBASE-14070, HBASE-14850, HBASE-16833, HBASE-15531, just
> >> name
> >>>> a few).  Cutting branch now would add burden to complete those
> projects.
> >>>>
> >>>> thanks
> >>>> Stephen
> >>>>
> >>>> On Sat, Dec 31, 2016 at 10:54 AM, Andrew Purtell <
> >> andrew.purtell@gmail.com
> >>>>>
> >>>> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I've heard a rumor the co-RM situation with 2.0 may have changed. Can
> >> we
> >>>>> get an update from co-RMs Matteo and Steven on their availability and
> >>>>> interest in continuing in this role?
> >>>>>
> >>>>> To assist in moving 2.0 forward I intend to branch branch-2 from
> master
> >>>>> next week. Unless there is an objection I will take this action under
> >>>>> assumption of lazy consensus. Master branch will be renumbered to
> >>>>> 3.0.0-SNAPSHOT. Once we have a branch-2 I will immediately begin
> scale
> >>>>> tests and stabilization (via bug fixes or reverts of unfinished work)
> >> and
> >>>>> invite interested collaborators to do the same.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>



-- 
Thanks,
Michael Antonov

Re: Moving 2.0 forward

[Andrew Purtell <an...@gmail.com>]

Considerations for a new branch-2 and branch-1 are orthogonal in my opinion. 

I intend to volunteer to be the RM for branch-1 itself (we've not had one before) as necessary for it to become a stable source of incremental releases for a long time, similar to how we had 0.98 active for almost three years while 1.x development took place. Where I work we plan to have branch-1 based code in production for at least one year, probably longer. 

Given the above arrangement, releases from branch-1 and branch-2 would have independent roadmaps and release timelines. 

Does this sound reasonable? 


> On Jan 5, 2017, at 11:51 PM, Phil Yang <ud...@gmail.com> wrote:
> 
> Hi all
> After cutting branch-2, what will we do for branch-1? If I am not wrong,
> 1.4 may be the last 1.x release branch? Should 1.4.0 release before 2.0.0?
> If not, will it confuse users?
> 
> Thanks,
> Phil
> 
> 
> 2017-01-01 5:20 GMT+08:00 Andrew Purtell <an...@gmail.com>:
> 
>> On the other hand branching will force the issue. There will always be
>> lists of issues to get in. How long have we been talking about 2.0? At
>> least a year and a half. At some point it's time to stop talking and take
>> action. Let me revisit progress at the end of January and bring this up
>> again. As a member of the PMC I'm advising all concerned that 2.0 is
>> talking too long and I am considering steps to move it forward.
>> 
>> 
>>> On Dec 31, 2016, at 12:54 PM, Ted Yu <yu...@gmail.com> wrote:
>>> 
>>> I agree with Stephen on not branching too early.
>>> 
>>> When people come back from vacation, we can poll relevant parties on
>>> estimate of respective project to get a sense of when would be proper
>> time
>>> for branching.
>>> 
>>> On Sat, Dec 31, 2016 at 12:16 PM, Stephen Jiang <syuanjiangdev@gmail.com
>>> 
>>> wrote:
>>> 
>>>> Hello, Andrew, I was a helper on Matteo so that we can help each other
>>>> while we are focusing on the new Assignment Manager work.  Now he is not
>>>> available (at least in the next few months).  I have to be more focused
>> on
>>>> the new AM work; plus other work in my company; it would be too much
>> for me
>>>> to 2.0 RM alone.  I am happy someone would help to take primary 2.0 RM
>> role
>>>> while I am still help to make this 2.0 release smooth.
>>>> 
>>>> For branch-2, I think it is too early to cut it, as we still have a lot
>> of
>>>> moving parts and on-going project that needs to be part of 2.0.  For
>>>> example, the mentioned new AM (and other projects, such as HBASE-14414,
>>>> HBASE-15179, HBASE-14070, HBASE-14850, HBASE-16833, HBASE-15531, just
>> name
>>>> a few).  Cutting branch now would add burden to complete those projects.
>>>> 
>>>> thanks
>>>> Stephen
>>>> 
>>>> On Sat, Dec 31, 2016 at 10:54 AM, Andrew Purtell <
>> andrew.purtell@gmail.com
>>>>> 
>>>> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I've heard a rumor the co-RM situation with 2.0 may have changed. Can
>> we
>>>>> get an update from co-RMs Matteo and Steven on their availability and
>>>>> interest in continuing in this role?
>>>>> 
>>>>> To assist in moving 2.0 forward I intend to branch branch-2 from master
>>>>> next week. Unless there is an objection I will take this action under
>>>>> assumption of lazy consensus. Master branch will be renumbered to
>>>>> 3.0.0-SNAPSHOT. Once we have a branch-2 I will immediately begin scale
>>>>> tests and stabilization (via bug fixes or reverts of unfinished work)
>> and
>>>>> invite interested collaborators to do the same.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>