You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "张铎 (Duo Zhang)" <pa...@gmail.com> on 2018/06/04 00:36:03 UTC

Re: On the 2.1.0 and 3.0.0 release

Will cut the 2.1 branch tomorrow if no objections. The unfinished features
will be disabled by default or purged from branch-2.1 and target to 2.2
release.

2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:

> Plan to cut branch-2.1 at the end of May. Will consider the status of the
> new features at that time to determine what will be released with 2.1.x
> release line.
>
> 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
>
>> Big big big +1
>>
>> (Came in to say just this but you beat me to it :D)
>>
>>
>> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
>>
>>> Let's do big features in 3.0.0 only.
>>>
>>> Ideally there will no big new features for a minor release, so that we
>>> can
>>> move the stable pointer to newer minor versions quickly and retire the
>>> old
>>> branches. It will be a nightmare if we have lots of active minor release
>>> lines...
>>>
>>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
>>>
>>> Why 2.1 doesn't contatin synchronous replication? This can be a
>>>> experiment
>>>> feature in 2.1?
>>>>
>>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>>>>
>>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
>>>>>
>>>>> As I volunteered to be the release manager for the 2.1 release line
>>>>>>>
>>>>>> so
>>>>
>>>>> let
>>>>>>
>>>>>>> me bring this up.
>>>>>>>
>>>>>> +1 to Duo be RM of 2.1 release.
>>>>>>
>>>>>> disabled from 2.0.0 release, for example, serial replication, and in
>>>>>>>
>>>>>> memory compaction
>>>>>> IIRC, in memory compaction is enabled in 2.0 and the default policy is
>>>>>> BASIC. (please correct me if I misunderstand something.)
>>>>>>
>>>>>> We disabled it by default in the end due to some performance issues...
>>>>>
>>>>>
>>>>>> For the 2.1 release line, I would like to define it as the 'real' 2.x
>>>>>>>
>>>>>> Seems the release date between 2.0 and 2.1 will be very close. Is it
>>>>>> related to our new release plan? (IIRC, Andrew had suggested some
>>>>>> great
>>>>>> release plan based time. But I fail to find the thread...)
>>>>>>
>>>>>> And for the 3.0.0 release, I think the new features should be decided
>>>>>>>
>>>>>> ASAP.
>>>>>>
>>>>>>> We need to avoid the same thing happens again, i.e, spending 2 years
>>>>>>>
>>>>>> to
>>>>
>>>>> release a major version...
>>>>>>>
>>>>>> agreed!
>>>>>>
>>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>>>>>>
>>>>>>> As I volunteered to be the release manager for the 2.1 release line
>>>>>>>
>>>>>> so
>>>>
>>>>> let
>>>>>>
>>>>>>> me bring this up.
>>>>>>>
>>>>>>> For the 2.1 release line, I would like to define it as the 'real' 2.x
>>>>>>> version of HBase. It should include the features which are reverted
>>>>>>>
>>>>>> or
>>>>
>>>>> disabled from 2.0.0 release, for example, serial replication, and in
>>>>>>>
>>>>>> memory
>>>>>>
>>>>>>> compaction. And also, the performance issues. And no more new
>>>>>>>
>>>>>> features.
>>>>
>>>>> If
>>>>>>
>>>>>>> no objections, I will start the release work soon.
>>>>>>>
>>>>>>> And for the 3.0.0 release, I think the new features should be decided
>>>>>>>
>>>>>> ASAP.
>>>>>>
>>>>>>> We need to avoid the same thing happens again, i.e, spending 2 years
>>>>>>>
>>>>>> to
>>>>
>>>>> release a major version...
>>>>>>>
>>>>>>> For now, the new features
>>>>>>> Synchronous replication
>>>>>>> CCSMap
>>>>>>> Backup
>>>>>>> Spark connector(is it still active?)
>>>>>>>
>>>>>>> And I suggest that we include this:
>>>>>>> The read path refactoring(HBASE-20525)
>>>>>>>
>>>>>>> Suggestions are welcomed.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Pushed branch-2.1 at this commit.

commit a86141b6252a433ff62f5c1979d7523031da0bf2
Author: zhangduo <zh...@apache.org>
Date:   Thu Jun 21 10:14:57 2018 +0800

    HBASE-20752 Make sure the regions are truly reopened after
ReopenTableRegionsProcedure

2018-06-22 15:10 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:

> Hold on committing to branch-2. Will cut branch-2.1 soon.
>
> 2018-06-19 22:05 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>
>> Moved a bunch of issues out of 2.1.0. You can add it back if you think
>> this is important for 2.1.0 release but we need to be quick. Will cut
>> branch-2.1 after finish the related issues around SCP and MRP, maybe end of
>> this week.
>>
>> Thanks.
>>
>> 2018-06-13 15:00 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>>
>>> I set HBASE-20708 as a blocker for 2.1.0 release, and I also think we
>>> need to address HBASE-20706. Will keep working on it.
>>>
>>> 2018-06-13 14:11 GMT+08:00 Stack <st...@duboce.net>:
>>>
>>>> On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) <pa...@gmail.com>
>>>> wrote:
>>>>
>>>> > What;s your plan sir? Branch branch-2.1 from branch-2.0?
>>>> >
>>>> >
>>>> Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0
>>>> --
>>>> but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful
>>>> lot
>>>> for a patch release (It is our first release after a major so we might
>>>> allow ourselves some slack) but they are just bug fixes and some perf
>>>> improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I
>>>> can see 2.0.2, 2.0.3 coming at about same interval but again just bug
>>>> fixes
>>>> and perf: no new features. I relinquish any claim on 2.1.0.
>>>>
>>>> S
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
>>>> >
>>>> > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <
>>>> palomino219@gmail.com>
>>>> > > wrote:
>>>> > >
>>>> > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
>>>> > > features
>>>> > > > will be disabled by default or purged from branch-2.1 and target
>>>> to 2.2
>>>> > > > release.
>>>> > > >
>>>> > > >
>>>> > > I was thinking that the next release off branch-2.0 could be 2.1.0.
>>>> It
>>>> > has
>>>> > > 70+ commits including a big boost in perf. It feels more like a
>>>> minor
>>>> > > release than it does a point release.
>>>> > >
>>>> > > Branch 3.0.0 rather than 2.1.0 Duo?
>>>> > >
>>>> > > S
>>>> > >
>>>> > >
>>>> > >
>>>> > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>>>> > > >
>>>> > > > > Plan to cut branch-2.1 at the end of May. Will consider the
>>>> status of
>>>> > > the
>>>> > > > > new features at that time to determine what will be released
>>>> with
>>>> > 2.1.x
>>>> > > > > release line.
>>>> > > > >
>>>> > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
>>>> > > > >
>>>> > > > >> Big big big +1
>>>> > > > >>
>>>> > > > >> (Came in to say just this but you beat me to it :D)
>>>> > > > >>
>>>> > > > >>
>>>> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
>>>> > > > >>
>>>> > > > >>> Let's do big features in 3.0.0 only.
>>>> > > > >>>
>>>> > > > >>> Ideally there will no big new features for a minor release,
>>>> so that
>>>> > > we
>>>> > > > >>> can
>>>> > > > >>> move the stable pointer to newer minor versions quickly and
>>>> retire
>>>> > > the
>>>> > > > >>> old
>>>> > > > >>> branches. It will be a nightmare if we have lots of active
>>>> minor
>>>> > > > release
>>>> > > > >>> lines...
>>>> > > > >>>
>>>> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zghaobac@gmail.com
>>>> >:
>>>> > > > >>>
>>>> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be
>>>> a
>>>> > > > >>>> experiment
>>>> > > > >>>> feature in 2.1?
>>>> > > > >>>>
>>>> > > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <
>>>> palomino219@gmail.com>:
>>>> > > > >>>>
>>>> > > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <
>>>> chia7712@apache.org>:
>>>> > > > >>>>>
>>>> > > > >>>>> As I volunteered to be the release manager for the 2.1
>>>> release
>>>> > line
>>>> > > > >>>>>>>
>>>> > > > >>>>>> so
>>>> > > > >>>>
>>>> > > > >>>>> let
>>>> > > > >>>>>>
>>>> > > > >>>>>>> me bring this up.
>>>> > > > >>>>>>>
>>>> > > > >>>>>> +1 to Duo be RM of 2.1 release.
>>>> > > > >>>>>>
>>>> > > > >>>>>> disabled from 2.0.0 release, for example, serial
>>>> replication,
>>>> > and
>>>> > > in
>>>> > > > >>>>>>>
>>>> > > > >>>>>> memory compaction
>>>> > > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the
>>>> default
>>>> > > policy
>>>> > > > is
>>>> > > > >>>>>> BASIC. (please correct me if I misunderstand something.)
>>>> > > > >>>>>>
>>>> > > > >>>>>> We disabled it by default in the end due to some
>>>> performance
>>>> > > > issues...
>>>> > > > >>>>>
>>>> > > > >>>>>
>>>> > > > >>>>>> For the 2.1 release line, I would like to define it as the
>>>> > 'real'
>>>> > > > 2.x
>>>> > > > >>>>>>>
>>>> > > > >>>>>> Seems the release date between 2.0 and 2.1 will be very
>>>> close.
>>>> > Is
>>>> > > it
>>>> > > > >>>>>> related to our new release plan? (IIRC, Andrew had
>>>> suggested
>>>> > some
>>>> > > > >>>>>> great
>>>> > > > >>>>>> release plan based time. But I fail to find the thread...)
>>>> > > > >>>>>>
>>>> > > > >>>>>> And for the 3.0.0 release, I think the new features should
>>>> be
>>>> > > > decided
>>>> > > > >>>>>>>
>>>> > > > >>>>>> ASAP.
>>>> > > > >>>>>>
>>>> > > > >>>>>>> We need to avoid the same thing happens again, i.e,
>>>> spending 2
>>>> > > > years
>>>> > > > >>>>>>>
>>>> > > > >>>>>> to
>>>> > > > >>>>
>>>> > > > >>>>> release a major version...
>>>> > > > >>>>>>>
>>>> > > > >>>>>> agreed!
>>>> > > > >>>>>>
>>>> > > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <
>>>> palomino219@gmail.com>
>>>> > > > wrote:
>>>> > > > >>>>>>
>>>> > > > >>>>>>> As I volunteered to be the release manager for the 2.1
>>>> release
>>>> > > line
>>>> > > > >>>>>>>
>>>> > > > >>>>>> so
>>>> > > > >>>>
>>>> > > > >>>>> let
>>>> > > > >>>>>>
>>>> > > > >>>>>>> me bring this up.
>>>> > > > >>>>>>>
>>>> > > > >>>>>>> For the 2.1 release line, I would like to define it as the
>>>> > 'real'
>>>> > > > 2.x
>>>> > > > >>>>>>> version of HBase. It should include the features which are
>>>> > > reverted
>>>> > > > >>>>>>>
>>>> > > > >>>>>> or
>>>> > > > >>>>
>>>> > > > >>>>> disabled from 2.0.0 release, for example, serial
>>>> replication, and
>>>> > > in
>>>> > > > >>>>>>>
>>>> > > > >>>>>> memory
>>>> > > > >>>>>>
>>>> > > > >>>>>>> compaction. And also, the performance issues. And no more
>>>> new
>>>> > > > >>>>>>>
>>>> > > > >>>>>> features.
>>>> > > > >>>>
>>>> > > > >>>>> If
>>>> > > > >>>>>>
>>>> > > > >>>>>>> no objections, I will start the release work soon.
>>>> > > > >>>>>>>
>>>> > > > >>>>>>> And for the 3.0.0 release, I think the new features
>>>> should be
>>>> > > > decided
>>>> > > > >>>>>>>
>>>> > > > >>>>>> ASAP.
>>>> > > > >>>>>>
>>>> > > > >>>>>>> We need to avoid the same thing happens again, i.e,
>>>> spending 2
>>>> > > > years
>>>> > > > >>>>>>>
>>>> > > > >>>>>> to
>>>> > > > >>>>
>>>> > > > >>>>> release a major version...
>>>> > > > >>>>>>>
>>>> > > > >>>>>>> For now, the new features
>>>> > > > >>>>>>> Synchronous replication
>>>> > > > >>>>>>> CCSMap
>>>> > > > >>>>>>> Backup
>>>> > > > >>>>>>> Spark connector(is it still active?)
>>>> > > > >>>>>>>
>>>> > > > >>>>>>> And I suggest that we include this:
>>>> > > > >>>>>>> The read path refactoring(HBASE-20525)
>>>> > > > >>>>>>>
>>>> > > > >>>>>>> Suggestions are welcomed.
>>>> > > > >>>>>>>
>>>> > > > >>>>>>> Thanks.
>>>> > > > >>>>>>>
>>>> > > > >>>>>>>
>>>> > > > >>>>>>
>>>> > > > >>>>>
>>>> > > > >>>>
>>>> > > > >>>
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Hold on committing to branch-2. Will cut branch-2.1 soon.

2018-06-19 22:05 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:

> Moved a bunch of issues out of 2.1.0. You can add it back if you think
> this is important for 2.1.0 release but we need to be quick. Will cut
> branch-2.1 after finish the related issues around SCP and MRP, maybe end of
> this week.
>
> Thanks.
>
> 2018-06-13 15:00 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>
>> I set HBASE-20708 as a blocker for 2.1.0 release, and I also think we
>> need to address HBASE-20706. Will keep working on it.
>>
>> 2018-06-13 14:11 GMT+08:00 Stack <st...@duboce.net>:
>>
>>> On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) <pa...@gmail.com>
>>> wrote:
>>>
>>> > What;s your plan sir? Branch branch-2.1 from branch-2.0?
>>> >
>>> >
>>> Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0
>>> --
>>> but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful lot
>>> for a patch release (It is our first release after a major so we might
>>> allow ourselves some slack) but they are just bug fixes and some perf
>>> improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I
>>> can see 2.0.2, 2.0.3 coming at about same interval but again just bug
>>> fixes
>>> and perf: no new features. I relinquish any claim on 2.1.0.
>>>
>>> S
>>>
>>>
>>>
>>>
>>>
>>> > 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
>>> >
>>> > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <palomino219@gmail.com
>>> >
>>> > > wrote:
>>> > >
>>> > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
>>> > > features
>>> > > > will be disabled by default or purged from branch-2.1 and target
>>> to 2.2
>>> > > > release.
>>> > > >
>>> > > >
>>> > > I was thinking that the next release off branch-2.0 could be 2.1.0.
>>> It
>>> > has
>>> > > 70+ commits including a big boost in perf. It feels more like a minor
>>> > > release than it does a point release.
>>> > >
>>> > > Branch 3.0.0 rather than 2.1.0 Duo?
>>> > >
>>> > > S
>>> > >
>>> > >
>>> > >
>>> > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>>> > > >
>>> > > > > Plan to cut branch-2.1 at the end of May. Will consider the
>>> status of
>>> > > the
>>> > > > > new features at that time to determine what will be released with
>>> > 2.1.x
>>> > > > > release line.
>>> > > > >
>>> > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
>>> > > > >
>>> > > > >> Big big big +1
>>> > > > >>
>>> > > > >> (Came in to say just this but you beat me to it :D)
>>> > > > >>
>>> > > > >>
>>> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
>>> > > > >>
>>> > > > >>> Let's do big features in 3.0.0 only.
>>> > > > >>>
>>> > > > >>> Ideally there will no big new features for a minor release, so
>>> that
>>> > > we
>>> > > > >>> can
>>> > > > >>> move the stable pointer to newer minor versions quickly and
>>> retire
>>> > > the
>>> > > > >>> old
>>> > > > >>> branches. It will be a nightmare if we have lots of active
>>> minor
>>> > > > release
>>> > > > >>> lines...
>>> > > > >>>
>>> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zghaobac@gmail.com
>>> >:
>>> > > > >>>
>>> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
>>> > > > >>>> experiment
>>> > > > >>>> feature in 2.1?
>>> > > > >>>>
>>> > > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <
>>> palomino219@gmail.com>:
>>> > > > >>>>
>>> > > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <
>>> chia7712@apache.org>:
>>> > > > >>>>>
>>> > > > >>>>> As I volunteered to be the release manager for the 2.1
>>> release
>>> > line
>>> > > > >>>>>>>
>>> > > > >>>>>> so
>>> > > > >>>>
>>> > > > >>>>> let
>>> > > > >>>>>>
>>> > > > >>>>>>> me bring this up.
>>> > > > >>>>>>>
>>> > > > >>>>>> +1 to Duo be RM of 2.1 release.
>>> > > > >>>>>>
>>> > > > >>>>>> disabled from 2.0.0 release, for example, serial
>>> replication,
>>> > and
>>> > > in
>>> > > > >>>>>>>
>>> > > > >>>>>> memory compaction
>>> > > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
>>> > > policy
>>> > > > is
>>> > > > >>>>>> BASIC. (please correct me if I misunderstand something.)
>>> > > > >>>>>>
>>> > > > >>>>>> We disabled it by default in the end due to some performance
>>> > > > issues...
>>> > > > >>>>>
>>> > > > >>>>>
>>> > > > >>>>>> For the 2.1 release line, I would like to define it as the
>>> > 'real'
>>> > > > 2.x
>>> > > > >>>>>>>
>>> > > > >>>>>> Seems the release date between 2.0 and 2.1 will be very
>>> close.
>>> > Is
>>> > > it
>>> > > > >>>>>> related to our new release plan? (IIRC, Andrew had suggested
>>> > some
>>> > > > >>>>>> great
>>> > > > >>>>>> release plan based time. But I fail to find the thread...)
>>> > > > >>>>>>
>>> > > > >>>>>> And for the 3.0.0 release, I think the new features should
>>> be
>>> > > > decided
>>> > > > >>>>>>>
>>> > > > >>>>>> ASAP.
>>> > > > >>>>>>
>>> > > > >>>>>>> We need to avoid the same thing happens again, i.e,
>>> spending 2
>>> > > > years
>>> > > > >>>>>>>
>>> > > > >>>>>> to
>>> > > > >>>>
>>> > > > >>>>> release a major version...
>>> > > > >>>>>>>
>>> > > > >>>>>> agreed!
>>> > > > >>>>>>
>>> > > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <
>>> palomino219@gmail.com>
>>> > > > wrote:
>>> > > > >>>>>>
>>> > > > >>>>>>> As I volunteered to be the release manager for the 2.1
>>> release
>>> > > line
>>> > > > >>>>>>>
>>> > > > >>>>>> so
>>> > > > >>>>
>>> > > > >>>>> let
>>> > > > >>>>>>
>>> > > > >>>>>>> me bring this up.
>>> > > > >>>>>>>
>>> > > > >>>>>>> For the 2.1 release line, I would like to define it as the
>>> > 'real'
>>> > > > 2.x
>>> > > > >>>>>>> version of HBase. It should include the features which are
>>> > > reverted
>>> > > > >>>>>>>
>>> > > > >>>>>> or
>>> > > > >>>>
>>> > > > >>>>> disabled from 2.0.0 release, for example, serial
>>> replication, and
>>> > > in
>>> > > > >>>>>>>
>>> > > > >>>>>> memory
>>> > > > >>>>>>
>>> > > > >>>>>>> compaction. And also, the performance issues. And no more
>>> new
>>> > > > >>>>>>>
>>> > > > >>>>>> features.
>>> > > > >>>>
>>> > > > >>>>> If
>>> > > > >>>>>>
>>> > > > >>>>>>> no objections, I will start the release work soon.
>>> > > > >>>>>>>
>>> > > > >>>>>>> And for the 3.0.0 release, I think the new features should
>>> be
>>> > > > decided
>>> > > > >>>>>>>
>>> > > > >>>>>> ASAP.
>>> > > > >>>>>>
>>> > > > >>>>>>> We need to avoid the same thing happens again, i.e,
>>> spending 2
>>> > > > years
>>> > > > >>>>>>>
>>> > > > >>>>>> to
>>> > > > >>>>
>>> > > > >>>>> release a major version...
>>> > > > >>>>>>>
>>> > > > >>>>>>> For now, the new features
>>> > > > >>>>>>> Synchronous replication
>>> > > > >>>>>>> CCSMap
>>> > > > >>>>>>> Backup
>>> > > > >>>>>>> Spark connector(is it still active?)
>>> > > > >>>>>>>
>>> > > > >>>>>>> And I suggest that we include this:
>>> > > > >>>>>>> The read path refactoring(HBASE-20525)
>>> > > > >>>>>>>
>>> > > > >>>>>>> Suggestions are welcomed.
>>> > > > >>>>>>>
>>> > > > >>>>>>> Thanks.
>>> > > > >>>>>>>
>>> > > > >>>>>>>
>>> > > > >>>>>>
>>> > > > >>>>>
>>> > > > >>>>
>>> > > > >>>
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Moved a bunch of issues out of 2.1.0. You can add it back if you think this
is important for 2.1.0 release but we need to be quick. Will cut branch-2.1
after finish the related issues around SCP and MRP, maybe end of this week.

Thanks.

2018-06-13 15:00 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:

> I set HBASE-20708 as a blocker for 2.1.0 release, and I also think we need
> to address HBASE-20706. Will keep working on it.
>
> 2018-06-13 14:11 GMT+08:00 Stack <st...@duboce.net>:
>
>> On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) <pa...@gmail.com>
>> wrote:
>>
>> > What;s your plan sir? Branch branch-2.1 from branch-2.0?
>> >
>> >
>> Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0 --
>> but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful lot
>> for a patch release (It is our first release after a major so we might
>> allow ourselves some slack) but they are just bug fixes and some perf
>> improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I
>> can see 2.0.2, 2.0.3 coming at about same interval but again just bug
>> fixes
>> and perf: no new features. I relinquish any claim on 2.1.0.
>>
>> S
>>
>>
>>
>>
>>
>> > 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
>> >
>> > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com>
>> > > wrote:
>> > >
>> > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
>> > > features
>> > > > will be disabled by default or purged from branch-2.1 and target to
>> 2.2
>> > > > release.
>> > > >
>> > > >
>> > > I was thinking that the next release off branch-2.0 could be 2.1.0. It
>> > has
>> > > 70+ commits including a big boost in perf. It feels more like a minor
>> > > release than it does a point release.
>> > >
>> > > Branch 3.0.0 rather than 2.1.0 Duo?
>> > >
>> > > S
>> > >
>> > >
>> > >
>> > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>> > > >
>> > > > > Plan to cut branch-2.1 at the end of May. Will consider the
>> status of
>> > > the
>> > > > > new features at that time to determine what will be released with
>> > 2.1.x
>> > > > > release line.
>> > > > >
>> > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
>> > > > >
>> > > > >> Big big big +1
>> > > > >>
>> > > > >> (Came in to say just this but you beat me to it :D)
>> > > > >>
>> > > > >>
>> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
>> > > > >>
>> > > > >>> Let's do big features in 3.0.0 only.
>> > > > >>>
>> > > > >>> Ideally there will no big new features for a minor release, so
>> that
>> > > we
>> > > > >>> can
>> > > > >>> move the stable pointer to newer minor versions quickly and
>> retire
>> > > the
>> > > > >>> old
>> > > > >>> branches. It will be a nightmare if we have lots of active minor
>> > > > release
>> > > > >>> lines...
>> > > > >>>
>> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
>> > > > >>>
>> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
>> > > > >>>> experiment
>> > > > >>>> feature in 2.1?
>> > > > >>>>
>> > > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <
>> palomino219@gmail.com>:
>> > > > >>>>
>> > > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <chia7712@apache.org
>> >:
>> > > > >>>>>
>> > > > >>>>> As I volunteered to be the release manager for the 2.1 release
>> > line
>> > > > >>>>>>>
>> > > > >>>>>> so
>> > > > >>>>
>> > > > >>>>> let
>> > > > >>>>>>
>> > > > >>>>>>> me bring this up.
>> > > > >>>>>>>
>> > > > >>>>>> +1 to Duo be RM of 2.1 release.
>> > > > >>>>>>
>> > > > >>>>>> disabled from 2.0.0 release, for example, serial replication,
>> > and
>> > > in
>> > > > >>>>>>>
>> > > > >>>>>> memory compaction
>> > > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
>> > > policy
>> > > > is
>> > > > >>>>>> BASIC. (please correct me if I misunderstand something.)
>> > > > >>>>>>
>> > > > >>>>>> We disabled it by default in the end due to some performance
>> > > > issues...
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>> For the 2.1 release line, I would like to define it as the
>> > 'real'
>> > > > 2.x
>> > > > >>>>>>>
>> > > > >>>>>> Seems the release date between 2.0 and 2.1 will be very
>> close.
>> > Is
>> > > it
>> > > > >>>>>> related to our new release plan? (IIRC, Andrew had suggested
>> > some
>> > > > >>>>>> great
>> > > > >>>>>> release plan based time. But I fail to find the thread...)
>> > > > >>>>>>
>> > > > >>>>>> And for the 3.0.0 release, I think the new features should be
>> > > > decided
>> > > > >>>>>>>
>> > > > >>>>>> ASAP.
>> > > > >>>>>>
>> > > > >>>>>>> We need to avoid the same thing happens again, i.e,
>> spending 2
>> > > > years
>> > > > >>>>>>>
>> > > > >>>>>> to
>> > > > >>>>
>> > > > >>>>> release a major version...
>> > > > >>>>>>>
>> > > > >>>>>> agreed!
>> > > > >>>>>>
>> > > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <palomino219@gmail.com
>> >
>> > > > wrote:
>> > > > >>>>>>
>> > > > >>>>>>> As I volunteered to be the release manager for the 2.1
>> release
>> > > line
>> > > > >>>>>>>
>> > > > >>>>>> so
>> > > > >>>>
>> > > > >>>>> let
>> > > > >>>>>>
>> > > > >>>>>>> me bring this up.
>> > > > >>>>>>>
>> > > > >>>>>>> For the 2.1 release line, I would like to define it as the
>> > 'real'
>> > > > 2.x
>> > > > >>>>>>> version of HBase. It should include the features which are
>> > > reverted
>> > > > >>>>>>>
>> > > > >>>>>> or
>> > > > >>>>
>> > > > >>>>> disabled from 2.0.0 release, for example, serial replication,
>> and
>> > > in
>> > > > >>>>>>>
>> > > > >>>>>> memory
>> > > > >>>>>>
>> > > > >>>>>>> compaction. And also, the performance issues. And no more
>> new
>> > > > >>>>>>>
>> > > > >>>>>> features.
>> > > > >>>>
>> > > > >>>>> If
>> > > > >>>>>>
>> > > > >>>>>>> no objections, I will start the release work soon.
>> > > > >>>>>>>
>> > > > >>>>>>> And for the 3.0.0 release, I think the new features should
>> be
>> > > > decided
>> > > > >>>>>>>
>> > > > >>>>>> ASAP.
>> > > > >>>>>>
>> > > > >>>>>>> We need to avoid the same thing happens again, i.e,
>> spending 2
>> > > > years
>> > > > >>>>>>>
>> > > > >>>>>> to
>> > > > >>>>
>> > > > >>>>> release a major version...
>> > > > >>>>>>>
>> > > > >>>>>>> For now, the new features
>> > > > >>>>>>> Synchronous replication
>> > > > >>>>>>> CCSMap
>> > > > >>>>>>> Backup
>> > > > >>>>>>> Spark connector(is it still active?)
>> > > > >>>>>>>
>> > > > >>>>>>> And I suggest that we include this:
>> > > > >>>>>>> The read path refactoring(HBASE-20525)
>> > > > >>>>>>>
>> > > > >>>>>>> Suggestions are welcomed.
>> > > > >>>>>>>
>> > > > >>>>>>> Thanks.
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>
>> > > > >>>>>
>> > > > >>>>
>> > > > >>>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
I set HBASE-20708 as a blocker for 2.1.0 release, and I also think we need
to address HBASE-20706. Will keep working on it.

2018-06-13 14:11 GMT+08:00 Stack <st...@duboce.net>:

> On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > What;s your plan sir? Branch branch-2.1 from branch-2.0?
> >
> >
> Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0 --
> but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful lot
> for a patch release (It is our first release after a major so we might
> allow ourselves some slack) but they are just bug fixes and some perf
> improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I
> can see 2.0.2, 2.0.3 coming at about same interval but again just bug fixes
> and perf: no new features. I relinquish any claim on 2.1.0.
>
> S
>
>
>
>
>
> > 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
> >
> > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com>
> > > wrote:
> > >
> > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
> > > features
> > > > will be disabled by default or purged from branch-2.1 and target to
> 2.2
> > > > release.
> > > >
> > > >
> > > I was thinking that the next release off branch-2.0 could be 2.1.0. It
> > has
> > > 70+ commits including a big boost in perf. It feels more like a minor
> > > release than it does a point release.
> > >
> > > Branch 3.0.0 rather than 2.1.0 Duo?
> > >
> > > S
> > >
> > >
> > >
> > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > > >
> > > > > Plan to cut branch-2.1 at the end of May. Will consider the status
> of
> > > the
> > > > > new features at that time to determine what will be released with
> > 2.1.x
> > > > > release line.
> > > > >
> > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> > > > >
> > > > >> Big big big +1
> > > > >>
> > > > >> (Came in to say just this but you beat me to it :D)
> > > > >>
> > > > >>
> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> > > > >>
> > > > >>> Let's do big features in 3.0.0 only.
> > > > >>>
> > > > >>> Ideally there will no big new features for a minor release, so
> that
> > > we
> > > > >>> can
> > > > >>> move the stable pointer to newer minor versions quickly and
> retire
> > > the
> > > > >>> old
> > > > >>> branches. It will be a nightmare if we have lots of active minor
> > > > release
> > > > >>> lines...
> > > > >>>
> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> > > > >>>
> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> > > > >>>> experiment
> > > > >>>> feature in 2.1?
> > > > >>>>
> > > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <palomino219@gmail.com
> >:
> > > > >>>>
> > > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <chia7712@apache.org
> >:
> > > > >>>>>
> > > > >>>>> As I volunteered to be the release manager for the 2.1 release
> > line
> > > > >>>>>>>
> > > > >>>>>> so
> > > > >>>>
> > > > >>>>> let
> > > > >>>>>>
> > > > >>>>>>> me bring this up.
> > > > >>>>>>>
> > > > >>>>>> +1 to Duo be RM of 2.1 release.
> > > > >>>>>>
> > > > >>>>>> disabled from 2.0.0 release, for example, serial replication,
> > and
> > > in
> > > > >>>>>>>
> > > > >>>>>> memory compaction
> > > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
> > > policy
> > > > is
> > > > >>>>>> BASIC. (please correct me if I misunderstand something.)
> > > > >>>>>>
> > > > >>>>>> We disabled it by default in the end due to some performance
> > > > issues...
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> For the 2.1 release line, I would like to define it as the
> > 'real'
> > > > 2.x
> > > > >>>>>>>
> > > > >>>>>> Seems the release date between 2.0 and 2.1 will be very close.
> > Is
> > > it
> > > > >>>>>> related to our new release plan? (IIRC, Andrew had suggested
> > some
> > > > >>>>>> great
> > > > >>>>>> release plan based time. But I fail to find the thread...)
> > > > >>>>>>
> > > > >>>>>> And for the 3.0.0 release, I think the new features should be
> > > > decided
> > > > >>>>>>>
> > > > >>>>>> ASAP.
> > > > >>>>>>
> > > > >>>>>>> We need to avoid the same thing happens again, i.e, spending
> 2
> > > > years
> > > > >>>>>>>
> > > > >>>>>> to
> > > > >>>>
> > > > >>>>> release a major version...
> > > > >>>>>>>
> > > > >>>>>> agreed!
> > > > >>>>>>
> > > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> > > > wrote:
> > > > >>>>>>
> > > > >>>>>>> As I volunteered to be the release manager for the 2.1
> release
> > > line
> > > > >>>>>>>
> > > > >>>>>> so
> > > > >>>>
> > > > >>>>> let
> > > > >>>>>>
> > > > >>>>>>> me bring this up.
> > > > >>>>>>>
> > > > >>>>>>> For the 2.1 release line, I would like to define it as the
> > 'real'
> > > > 2.x
> > > > >>>>>>> version of HBase. It should include the features which are
> > > reverted
> > > > >>>>>>>
> > > > >>>>>> or
> > > > >>>>
> > > > >>>>> disabled from 2.0.0 release, for example, serial replication,
> and
> > > in
> > > > >>>>>>>
> > > > >>>>>> memory
> > > > >>>>>>
> > > > >>>>>>> compaction. And also, the performance issues. And no more new
> > > > >>>>>>>
> > > > >>>>>> features.
> > > > >>>>
> > > > >>>>> If
> > > > >>>>>>
> > > > >>>>>>> no objections, I will start the release work soon.
> > > > >>>>>>>
> > > > >>>>>>> And for the 3.0.0 release, I think the new features should be
> > > > decided
> > > > >>>>>>>
> > > > >>>>>> ASAP.
> > > > >>>>>>
> > > > >>>>>>> We need to avoid the same thing happens again, i.e, spending
> 2
> > > > years
> > > > >>>>>>>
> > > > >>>>>> to
> > > > >>>>
> > > > >>>>> release a major version...
> > > > >>>>>>>
> > > > >>>>>>> For now, the new features
> > > > >>>>>>> Synchronous replication
> > > > >>>>>>> CCSMap
> > > > >>>>>>> Backup
> > > > >>>>>>> Spark connector(is it still active?)
> > > > >>>>>>>
> > > > >>>>>>> And I suggest that we include this:
> > > > >>>>>>> The read path refactoring(HBASE-20525)
> > > > >>>>>>>
> > > > >>>>>>> Suggestions are welcomed.
> > > > >>>>>>>
> > > > >>>>>>> Thanks.
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >
> > > >
> > >
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by Stack <st...@duboce.net>.
On Sun, Jun 3, 2018 at 8:54 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> What;s your plan sir? Branch branch-2.1 from branch-2.0?
>
>
Dang. Its time to push out a new release -- it is > 6 weeks since 2.0.0 --
but I'll just call it 2.0.1. It has 70+ fixes in it which is an awful lot
for a patch release (It is our first release after a major so we might
allow ourselves some slack) but they are just bug fixes and some perf
improvements; it doesn't feel substantial enough (yet) to claim 2.1.0. I
can see 2.0.2, 2.0.3 coming at about same interval but again just bug fixes
and perf: no new features. I relinquish any claim on 2.1.0.

S





> 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
>
> > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
> > features
> > > will be disabled by default or purged from branch-2.1 and target to 2.2
> > > release.
> > >
> > >
> > I was thinking that the next release off branch-2.0 could be 2.1.0. It
> has
> > 70+ commits including a big boost in perf. It feels more like a minor
> > release than it does a point release.
> >
> > Branch 3.0.0 rather than 2.1.0 Duo?
> >
> > S
> >
> >
> >
> > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > >
> > > > Plan to cut branch-2.1 at the end of May. Will consider the status of
> > the
> > > > new features at that time to determine what will be released with
> 2.1.x
> > > > release line.
> > > >
> > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> > > >
> > > >> Big big big +1
> > > >>
> > > >> (Came in to say just this but you beat me to it :D)
> > > >>
> > > >>
> > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> > > >>
> > > >>> Let's do big features in 3.0.0 only.
> > > >>>
> > > >>> Ideally there will no big new features for a minor release, so that
> > we
> > > >>> can
> > > >>> move the stable pointer to newer minor versions quickly and retire
> > the
> > > >>> old
> > > >>> branches. It will be a nightmare if we have lots of active minor
> > > release
> > > >>> lines...
> > > >>>
> > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> > > >>>
> > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> > > >>>> experiment
> > > >>>> feature in 2.1?
> > > >>>>
> > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > > >>>>
> > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
> > > >>>>>
> > > >>>>> As I volunteered to be the release manager for the 2.1 release
> line
> > > >>>>>>>
> > > >>>>>> so
> > > >>>>
> > > >>>>> let
> > > >>>>>>
> > > >>>>>>> me bring this up.
> > > >>>>>>>
> > > >>>>>> +1 to Duo be RM of 2.1 release.
> > > >>>>>>
> > > >>>>>> disabled from 2.0.0 release, for example, serial replication,
> and
> > in
> > > >>>>>>>
> > > >>>>>> memory compaction
> > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
> > policy
> > > is
> > > >>>>>> BASIC. (please correct me if I misunderstand something.)
> > > >>>>>>
> > > >>>>>> We disabled it by default in the end due to some performance
> > > issues...
> > > >>>>>
> > > >>>>>
> > > >>>>>> For the 2.1 release line, I would like to define it as the
> 'real'
> > > 2.x
> > > >>>>>>>
> > > >>>>>> Seems the release date between 2.0 and 2.1 will be very close.
> Is
> > it
> > > >>>>>> related to our new release plan? (IIRC, Andrew had suggested
> some
> > > >>>>>> great
> > > >>>>>> release plan based time. But I fail to find the thread...)
> > > >>>>>>
> > > >>>>>> And for the 3.0.0 release, I think the new features should be
> > > decided
> > > >>>>>>>
> > > >>>>>> ASAP.
> > > >>>>>>
> > > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > > years
> > > >>>>>>>
> > > >>>>>> to
> > > >>>>
> > > >>>>> release a major version...
> > > >>>>>>>
> > > >>>>>> agreed!
> > > >>>>>>
> > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> > > wrote:
> > > >>>>>>
> > > >>>>>>> As I volunteered to be the release manager for the 2.1 release
> > line
> > > >>>>>>>
> > > >>>>>> so
> > > >>>>
> > > >>>>> let
> > > >>>>>>
> > > >>>>>>> me bring this up.
> > > >>>>>>>
> > > >>>>>>> For the 2.1 release line, I would like to define it as the
> 'real'
> > > 2.x
> > > >>>>>>> version of HBase. It should include the features which are
> > reverted
> > > >>>>>>>
> > > >>>>>> or
> > > >>>>
> > > >>>>> disabled from 2.0.0 release, for example, serial replication, and
> > in
> > > >>>>>>>
> > > >>>>>> memory
> > > >>>>>>
> > > >>>>>>> compaction. And also, the performance issues. And no more new
> > > >>>>>>>
> > > >>>>>> features.
> > > >>>>
> > > >>>>> If
> > > >>>>>>
> > > >>>>>>> no objections, I will start the release work soon.
> > > >>>>>>>
> > > >>>>>>> And for the 3.0.0 release, I think the new features should be
> > > decided
> > > >>>>>>>
> > > >>>>>> ASAP.
> > > >>>>>>
> > > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > > years
> > > >>>>>>>
> > > >>>>>> to
> > > >>>>
> > > >>>>> release a major version...
> > > >>>>>>>
> > > >>>>>>> For now, the new features
> > > >>>>>>> Synchronous replication
> > > >>>>>>> CCSMap
> > > >>>>>>> Backup
> > > >>>>>>> Spark connector(is it still active?)
> > > >>>>>>>
> > > >>>>>>> And I suggest that we include this:
> > > >>>>>>> The read path refactoring(HBASE-20525)
> > > >>>>>>>
> > > >>>>>>> Suggestions are welcomed.
> > > >>>>>>>
> > > >>>>>>> Thanks.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >
> > >
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
https://issues.apache.org/jira/browse/HBASE-20682

This is a big problem for both branch-2 and branch-2.0 so will wait for a
bit until we can make sure there is no problem. Hope this could be done
this week.

2018-06-05 9:35 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:

> Anyway for 3.0 I think we need to have something new.
>
> And I think we could make use of feature branch more, so it will not delay
> the release. We can focus on the progress of the most important features
> and make sure they can be done before the release, and for other features,
> just do not merge them back if they are not ready yet and target to the
> next major/minor release.
>
> 2018-06-05 7:14 GMT+08:00 Josh Elser <el...@apache.org>:
>
>> On 6/4/18 12:16 AM, Stack wrote:
>>
>>> On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang)<pa...@gmail.com>
>>> wrote:
>>>
>>> What;s your plan sir? Branch branch-2.1 from branch-2.0?
>>>>
>>>>
>>>> Its a suggestion.
>>>
>>> I like Andrew's notion that we left-shift how we have been thinking about
>>> version numbers; that we releases tend toward minor increments rather
>>> than
>>> patch increments as we have been doing up to this.
>>>
>>> If we are going to act on Andrew's suggestion, now is the time to do it.
>>>
>>> 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but
>>> with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in
>>> production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring
>>> bug
>>> and perf improvements only.
>>>
>>> We already have enough to define a substantial 3.0.0 IMO what with serial
>>> replication and HBASE-20312 CCSMap.
>>>
>>> I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to
>>> ship. Meantime we accumulate a mountain of testing, perf, and whatever
>>> else
>>> tech debt.
>>>
>>> What do folks think?
>>>
>>
>> mmmm, that's a good point. We keep saying that we aren't going to fall
>> into the same trap over and over, yet here we are setting ourselves up to
>> do it again :)
>>
>> I would have no complaints against 2.0.0+ becoming 2.1.0, but I feel like
>> that would make Duo's RM life harder too (assuming branch-2 is more stable
>> than master).
>>
>> I honestly don't know how to balance that. Someone eventually has to bite
>> the bullet :\
>>
>
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Anyway for 3.0 I think we need to have something new.

And I think we could make use of feature branch more, so it will not delay
the release. We can focus on the progress of the most important features
and make sure they can be done before the release, and for other features,
just do not merge them back if they are not ready yet and target to the
next major/minor release.

2018-06-05 7:14 GMT+08:00 Josh Elser <el...@apache.org>:

> On 6/4/18 12:16 AM, Stack wrote:
>
>> On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang)<pa...@gmail.com>
>> wrote:
>>
>> What;s your plan sir? Branch branch-2.1 from branch-2.0?
>>>
>>>
>>> Its a suggestion.
>>
>> I like Andrew's notion that we left-shift how we have been thinking about
>> version numbers; that we releases tend toward minor increments rather than
>> patch increments as we have been doing up to this.
>>
>> If we are going to act on Andrew's suggestion, now is the time to do it.
>>
>> 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but
>> with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in
>> production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug
>> and perf improvements only.
>>
>> We already have enough to define a substantial 3.0.0 IMO what with serial
>> replication and HBASE-20312 CCSMap.
>>
>> I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to
>> ship. Meantime we accumulate a mountain of testing, perf, and whatever
>> else
>> tech debt.
>>
>> What do folks think?
>>
>
> mmmm, that's a good point. We keep saying that we aren't going to fall
> into the same trap over and over, yet here we are setting ourselves up to
> do it again :)
>
> I would have no complaints against 2.0.0+ becoming 2.1.0, but I feel like
> that would make Duo's RM life harder too (assuming branch-2 is more stable
> than master).
>
> I honestly don't know how to balance that. Someone eventually has to bite
> the bullet :\
>

Re: On the 2.1.0 and 3.0.0 release

Posted by Josh Elser <el...@apache.org>.
On 6/4/18 12:16 AM, Stack wrote:
> On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang)<pa...@gmail.com>  wrote:
> 
>> What;s your plan sir? Branch branch-2.1 from branch-2.0?
>>
>>
> Its a suggestion.
> 
> I like Andrew's notion that we left-shift how we have been thinking about
> version numbers; that we releases tend toward minor increments rather than
> patch increments as we have been doing up to this.
> 
> If we are going to act on Andrew's suggestion, now is the time to do it.
> 
> 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but
> with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in
> production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug
> and perf improvements only.
> 
> We already have enough to define a substantial 3.0.0 IMO what with serial
> replication and HBASE-20312 CCSMap.
> 
> I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to
> ship. Meantime we accumulate a mountain of testing, perf, and whatever else
> tech debt.
> 
> What do folks think?

mmmm, that's a good point. We keep saying that we aren't going to fall 
into the same trap over and over, yet here we are setting ourselves up 
to do it again :)

I would have no complaints against 2.0.0+ becoming 2.1.0, but I feel 
like that would make Duo's RM life harder too (assuming branch-2 is more 
stable than master).

I honestly don't know how to balance that. Someone eventually has to 
bite the bullet :\

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
I think it is expected that we have more patch releases for minor releases
like 2.0.x and 1.1.x. As a new major release is expected to be unstable in
the beginning.

Even if we want to retire 2.0.x ASAP, I still think we need a have a 2.0.1
release...

Stack <st...@duboce.net>于2018年6月4日 周一12:16写道:

> On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > What;s your plan sir? Branch branch-2.1 from branch-2.0?
> >
> >
> Its a suggestion.
>
> I like Andrew's notion that we left-shift how we have been thinking about
> version numbers; that we releases tend toward minor increments rather than
> patch increments as we have been doing up to this.
>
> If we are going to act on Andrew's suggestion, now is the time to do it.
>
> 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but
> with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in
> production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug
> and perf improvements only.
>
> We already have enough to define a substantial 3.0.0 IMO what with serial
> replication and HBASE-20312 CCSMap.
>
> I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to
> ship. Meantime we accumulate a mountain of testing, perf, and whatever else
> tech debt.
>
> What do folks think?
>
> Thanks,
> S
>
>
>
>
> > 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
> >
> > > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com>
> > > wrote:
> > >
> > > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
> > > features
> > > > will be disabled by default or purged from branch-2.1 and target to
> 2.2
> > > > release.
> > > >
> > > >
> > > I was thinking that the next release off branch-2.0 could be 2.1.0. It
> > has
> > > 70+ commits including a big boost in perf. It feels more like a minor
> > > release than it does a point release.
> > >
> > > Branch 3.0.0 rather than 2.1.0 Duo?
> > >
> > > S
> > >
> > >
> > >
> > > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > > >
> > > > > Plan to cut branch-2.1 at the end of May. Will consider the status
> of
> > > the
> > > > > new features at that time to determine what will be released with
> > 2.1.x
> > > > > release line.
> > > > >
> > > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> > > > >
> > > > >> Big big big +1
> > > > >>
> > > > >> (Came in to say just this but you beat me to it :D)
> > > > >>
> > > > >>
> > > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> > > > >>
> > > > >>> Let's do big features in 3.0.0 only.
> > > > >>>
> > > > >>> Ideally there will no big new features for a minor release, so
> that
> > > we
> > > > >>> can
> > > > >>> move the stable pointer to newer minor versions quickly and
> retire
> > > the
> > > > >>> old
> > > > >>> branches. It will be a nightmare if we have lots of active minor
> > > > release
> > > > >>> lines...
> > > > >>>
> > > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> > > > >>>
> > > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> > > > >>>> experiment
> > > > >>>> feature in 2.1?
> > > > >>>>
> > > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <palomino219@gmail.com
> >:
> > > > >>>>
> > > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <chia7712@apache.org
> >:
> > > > >>>>>
> > > > >>>>> As I volunteered to be the release manager for the 2.1 release
> > line
> > > > >>>>>>>
> > > > >>>>>> so
> > > > >>>>
> > > > >>>>> let
> > > > >>>>>>
> > > > >>>>>>> me bring this up.
> > > > >>>>>>>
> > > > >>>>>> +1 to Duo be RM of 2.1 release.
> > > > >>>>>>
> > > > >>>>>> disabled from 2.0.0 release, for example, serial replication,
> > and
> > > in
> > > > >>>>>>>
> > > > >>>>>> memory compaction
> > > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
> > > policy
> > > > is
> > > > >>>>>> BASIC. (please correct me if I misunderstand something.)
> > > > >>>>>>
> > > > >>>>>> We disabled it by default in the end due to some performance
> > > > issues...
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> For the 2.1 release line, I would like to define it as the
> > 'real'
> > > > 2.x
> > > > >>>>>>>
> > > > >>>>>> Seems the release date between 2.0 and 2.1 will be very close.
> > Is
> > > it
> > > > >>>>>> related to our new release plan? (IIRC, Andrew had suggested
> > some
> > > > >>>>>> great
> > > > >>>>>> release plan based time. But I fail to find the thread...)
> > > > >>>>>>
> > > > >>>>>> And for the 3.0.0 release, I think the new features should be
> > > > decided
> > > > >>>>>>>
> > > > >>>>>> ASAP.
> > > > >>>>>>
> > > > >>>>>>> We need to avoid the same thing happens again, i.e, spending
> 2
> > > > years
> > > > >>>>>>>
> > > > >>>>>> to
> > > > >>>>
> > > > >>>>> release a major version...
> > > > >>>>>>>
> > > > >>>>>> agreed!
> > > > >>>>>>
> > > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> > > > wrote:
> > > > >>>>>>
> > > > >>>>>>> As I volunteered to be the release manager for the 2.1
> release
> > > line
> > > > >>>>>>>
> > > > >>>>>> so
> > > > >>>>
> > > > >>>>> let
> > > > >>>>>>
> > > > >>>>>>> me bring this up.
> > > > >>>>>>>
> > > > >>>>>>> For the 2.1 release line, I would like to define it as the
> > 'real'
> > > > 2.x
> > > > >>>>>>> version of HBase. It should include the features which are
> > > reverted
> > > > >>>>>>>
> > > > >>>>>> or
> > > > >>>>
> > > > >>>>> disabled from 2.0.0 release, for example, serial replication,
> and
> > > in
> > > > >>>>>>>
> > > > >>>>>> memory
> > > > >>>>>>
> > > > >>>>>>> compaction. And also, the performance issues. And no more new
> > > > >>>>>>>
> > > > >>>>>> features.
> > > > >>>>
> > > > >>>>> If
> > > > >>>>>>
> > > > >>>>>>> no objections, I will start the release work soon.
> > > > >>>>>>>
> > > > >>>>>>> And for the 3.0.0 release, I think the new features should be
> > > > decided
> > > > >>>>>>>
> > > > >>>>>> ASAP.
> > > > >>>>>>
> > > > >>>>>>> We need to avoid the same thing happens again, i.e, spending
> 2
> > > > years
> > > > >>>>>>>
> > > > >>>>>> to
> > > > >>>>
> > > > >>>>> release a major version...
> > > > >>>>>>>
> > > > >>>>>>> For now, the new features
> > > > >>>>>>> Synchronous replication
> > > > >>>>>>> CCSMap
> > > > >>>>>>> Backup
> > > > >>>>>>> Spark connector(is it still active?)
> > > > >>>>>>>
> > > > >>>>>>> And I suggest that we include this:
> > > > >>>>>>> The read path refactoring(HBASE-20525)
> > > > >>>>>>>
> > > > >>>>>>> Suggestions are welcomed.
> > > > >>>>>>>
> > > > >>>>>>> Thanks.
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >
> > > >
> > >
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by Stack <st...@duboce.net>.
On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> What;s your plan sir? Branch branch-2.1 from branch-2.0?
>
>
Its a suggestion.

I like Andrew's notion that we left-shift how we have been thinking about
version numbers; that we releases tend toward minor increments rather than
patch increments as we have been doing up to this.

If we are going to act on Andrew's suggestion, now is the time to do it.

2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but
with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in
production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug
and perf improvements only.

We already have enough to define a substantial 3.0.0 IMO what with serial
replication and HBASE-20312 CCSMap.

I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to
ship. Meantime we accumulate a mountain of testing, perf, and whatever else
tech debt.

What do folks think?

Thanks,
S




> 2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:
>
> > On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> > > Will cut the 2.1 branch tomorrow if no objections. The unfinished
> > features
> > > will be disabled by default or purged from branch-2.1 and target to 2.2
> > > release.
> > >
> > >
> > I was thinking that the next release off branch-2.0 could be 2.1.0. It
> has
> > 70+ commits including a big boost in perf. It feels more like a minor
> > release than it does a point release.
> >
> > Branch 3.0.0 rather than 2.1.0 Duo?
> >
> > S
> >
> >
> >
> > > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > >
> > > > Plan to cut branch-2.1 at the end of May. Will consider the status of
> > the
> > > > new features at that time to determine what will be released with
> 2.1.x
> > > > release line.
> > > >
> > > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> > > >
> > > >> Big big big +1
> > > >>
> > > >> (Came in to say just this but you beat me to it :D)
> > > >>
> > > >>
> > > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> > > >>
> > > >>> Let's do big features in 3.0.0 only.
> > > >>>
> > > >>> Ideally there will no big new features for a minor release, so that
> > we
> > > >>> can
> > > >>> move the stable pointer to newer minor versions quickly and retire
> > the
> > > >>> old
> > > >>> branches. It will be a nightmare if we have lots of active minor
> > > release
> > > >>> lines...
> > > >>>
> > > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> > > >>>
> > > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> > > >>>> experiment
> > > >>>> feature in 2.1?
> > > >>>>
> > > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > > >>>>
> > > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
> > > >>>>>
> > > >>>>> As I volunteered to be the release manager for the 2.1 release
> line
> > > >>>>>>>
> > > >>>>>> so
> > > >>>>
> > > >>>>> let
> > > >>>>>>
> > > >>>>>>> me bring this up.
> > > >>>>>>>
> > > >>>>>> +1 to Duo be RM of 2.1 release.
> > > >>>>>>
> > > >>>>>> disabled from 2.0.0 release, for example, serial replication,
> and
> > in
> > > >>>>>>>
> > > >>>>>> memory compaction
> > > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
> > policy
> > > is
> > > >>>>>> BASIC. (please correct me if I misunderstand something.)
> > > >>>>>>
> > > >>>>>> We disabled it by default in the end due to some performance
> > > issues...
> > > >>>>>
> > > >>>>>
> > > >>>>>> For the 2.1 release line, I would like to define it as the
> 'real'
> > > 2.x
> > > >>>>>>>
> > > >>>>>> Seems the release date between 2.0 and 2.1 will be very close.
> Is
> > it
> > > >>>>>> related to our new release plan? (IIRC, Andrew had suggested
> some
> > > >>>>>> great
> > > >>>>>> release plan based time. But I fail to find the thread...)
> > > >>>>>>
> > > >>>>>> And for the 3.0.0 release, I think the new features should be
> > > decided
> > > >>>>>>>
> > > >>>>>> ASAP.
> > > >>>>>>
> > > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > > years
> > > >>>>>>>
> > > >>>>>> to
> > > >>>>
> > > >>>>> release a major version...
> > > >>>>>>>
> > > >>>>>> agreed!
> > > >>>>>>
> > > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> > > wrote:
> > > >>>>>>
> > > >>>>>>> As I volunteered to be the release manager for the 2.1 release
> > line
> > > >>>>>>>
> > > >>>>>> so
> > > >>>>
> > > >>>>> let
> > > >>>>>>
> > > >>>>>>> me bring this up.
> > > >>>>>>>
> > > >>>>>>> For the 2.1 release line, I would like to define it as the
> 'real'
> > > 2.x
> > > >>>>>>> version of HBase. It should include the features which are
> > reverted
> > > >>>>>>>
> > > >>>>>> or
> > > >>>>
> > > >>>>> disabled from 2.0.0 release, for example, serial replication, and
> > in
> > > >>>>>>>
> > > >>>>>> memory
> > > >>>>>>
> > > >>>>>>> compaction. And also, the performance issues. And no more new
> > > >>>>>>>
> > > >>>>>> features.
> > > >>>>
> > > >>>>> If
> > > >>>>>>
> > > >>>>>>> no objections, I will start the release work soon.
> > > >>>>>>>
> > > >>>>>>> And for the 3.0.0 release, I think the new features should be
> > > decided
> > > >>>>>>>
> > > >>>>>> ASAP.
> > > >>>>>>
> > > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > > years
> > > >>>>>>>
> > > >>>>>> to
> > > >>>>
> > > >>>>> release a major version...
> > > >>>>>>>
> > > >>>>>>> For now, the new features
> > > >>>>>>> Synchronous replication
> > > >>>>>>> CCSMap
> > > >>>>>>> Backup
> > > >>>>>>> Spark connector(is it still active?)
> > > >>>>>>>
> > > >>>>>>> And I suggest that we include this:
> > > >>>>>>> The read path refactoring(HBASE-20525)
> > > >>>>>>>
> > > >>>>>>> Suggestions are welcomed.
> > > >>>>>>>
> > > >>>>>>> Thanks.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >
> > >
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
What;s your plan sir? Branch branch-2.1 from branch-2.0?

2018-06-04 11:50 GMT+08:00 Stack <st...@duboce.net>:

> On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > Will cut the 2.1 branch tomorrow if no objections. The unfinished
> features
> > will be disabled by default or purged from branch-2.1 and target to 2.2
> > release.
> >
> >
> I was thinking that the next release off branch-2.0 could be 2.1.0. It has
> 70+ commits including a big boost in perf. It feels more like a minor
> release than it does a point release.
>
> Branch 3.0.0 rather than 2.1.0 Duo?
>
> S
>
>
>
> > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> >
> > > Plan to cut branch-2.1 at the end of May. Will consider the status of
> the
> > > new features at that time to determine what will be released with 2.1.x
> > > release line.
> > >
> > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> > >
> > >> Big big big +1
> > >>
> > >> (Came in to say just this but you beat me to it :D)
> > >>
> > >>
> > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> > >>
> > >>> Let's do big features in 3.0.0 only.
> > >>>
> > >>> Ideally there will no big new features for a minor release, so that
> we
> > >>> can
> > >>> move the stable pointer to newer minor versions quickly and retire
> the
> > >>> old
> > >>> branches. It will be a nightmare if we have lots of active minor
> > release
> > >>> lines...
> > >>>
> > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> > >>>
> > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> > >>>> experiment
> > >>>> feature in 2.1?
> > >>>>
> > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > >>>>
> > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
> > >>>>>
> > >>>>> As I volunteered to be the release manager for the 2.1 release line
> > >>>>>>>
> > >>>>>> so
> > >>>>
> > >>>>> let
> > >>>>>>
> > >>>>>>> me bring this up.
> > >>>>>>>
> > >>>>>> +1 to Duo be RM of 2.1 release.
> > >>>>>>
> > >>>>>> disabled from 2.0.0 release, for example, serial replication, and
> in
> > >>>>>>>
> > >>>>>> memory compaction
> > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
> policy
> > is
> > >>>>>> BASIC. (please correct me if I misunderstand something.)
> > >>>>>>
> > >>>>>> We disabled it by default in the end due to some performance
> > issues...
> > >>>>>
> > >>>>>
> > >>>>>> For the 2.1 release line, I would like to define it as the 'real'
> > 2.x
> > >>>>>>>
> > >>>>>> Seems the release date between 2.0 and 2.1 will be very close. Is
> it
> > >>>>>> related to our new release plan? (IIRC, Andrew had suggested some
> > >>>>>> great
> > >>>>>> release plan based time. But I fail to find the thread...)
> > >>>>>>
> > >>>>>> And for the 3.0.0 release, I think the new features should be
> > decided
> > >>>>>>>
> > >>>>>> ASAP.
> > >>>>>>
> > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > years
> > >>>>>>>
> > >>>>>> to
> > >>>>
> > >>>>> release a major version...
> > >>>>>>>
> > >>>>>> agreed!
> > >>>>>>
> > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> > >>>>>>
> > >>>>>>> As I volunteered to be the release manager for the 2.1 release
> line
> > >>>>>>>
> > >>>>>> so
> > >>>>
> > >>>>> let
> > >>>>>>
> > >>>>>>> me bring this up.
> > >>>>>>>
> > >>>>>>> For the 2.1 release line, I would like to define it as the 'real'
> > 2.x
> > >>>>>>> version of HBase. It should include the features which are
> reverted
> > >>>>>>>
> > >>>>>> or
> > >>>>
> > >>>>> disabled from 2.0.0 release, for example, serial replication, and
> in
> > >>>>>>>
> > >>>>>> memory
> > >>>>>>
> > >>>>>>> compaction. And also, the performance issues. And no more new
> > >>>>>>>
> > >>>>>> features.
> > >>>>
> > >>>>> If
> > >>>>>>
> > >>>>>>> no objections, I will start the release work soon.
> > >>>>>>>
> > >>>>>>> And for the 3.0.0 release, I think the new features should be
> > decided
> > >>>>>>>
> > >>>>>> ASAP.
> > >>>>>>
> > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > years
> > >>>>>>>
> > >>>>>> to
> > >>>>
> > >>>>> release a major version...
> > >>>>>>>
> > >>>>>>> For now, the new features
> > >>>>>>> Synchronous replication
> > >>>>>>> CCSMap
> > >>>>>>> Backup
> > >>>>>>> Spark connector(is it still active?)
> > >>>>>>>
> > >>>>>>> And I suggest that we include this:
> > >>>>>>> The read path refactoring(HBASE-20525)
> > >>>>>>>
> > >>>>>>> Suggestions are welcomed.
> > >>>>>>>
> > >>>>>>> Thanks.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by Stack <st...@duboce.net>.
On Sun, Jun 3, 2018 at 5:36 PM, 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Will cut the 2.1 branch tomorrow if no objections. The unfinished features
> will be disabled by default or purged from branch-2.1 and target to 2.2
> release.
>
>
I was thinking that the next release off branch-2.0 could be 2.1.0. It has
70+ commits including a big boost in perf. It feels more like a minor
release than it does a point release.

Branch 3.0.0 rather than 2.1.0 Duo?

S



> 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>
> > Plan to cut branch-2.1 at the end of May. Will consider the status of the
> > new features at that time to determine what will be released with 2.1.x
> > release line.
> >
> > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> >
> >> Big big big +1
> >>
> >> (Came in to say just this but you beat me to it :D)
> >>
> >>
> >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> >>
> >>> Let's do big features in 3.0.0 only.
> >>>
> >>> Ideally there will no big new features for a minor release, so that we
> >>> can
> >>> move the stable pointer to newer minor versions quickly and retire the
> >>> old
> >>> branches. It will be a nightmare if we have lots of active minor
> release
> >>> lines...
> >>>
> >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> >>>
> >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> >>>> experiment
> >>>> feature in 2.1?
> >>>>
> >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> >>>>
> >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
> >>>>>
> >>>>> As I volunteered to be the release manager for the 2.1 release line
> >>>>>>>
> >>>>>> so
> >>>>
> >>>>> let
> >>>>>>
> >>>>>>> me bring this up.
> >>>>>>>
> >>>>>> +1 to Duo be RM of 2.1 release.
> >>>>>>
> >>>>>> disabled from 2.0.0 release, for example, serial replication, and in
> >>>>>>>
> >>>>>> memory compaction
> >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default policy
> is
> >>>>>> BASIC. (please correct me if I misunderstand something.)
> >>>>>>
> >>>>>> We disabled it by default in the end due to some performance
> issues...
> >>>>>
> >>>>>
> >>>>>> For the 2.1 release line, I would like to define it as the 'real'
> 2.x
> >>>>>>>
> >>>>>> Seems the release date between 2.0 and 2.1 will be very close. Is it
> >>>>>> related to our new release plan? (IIRC, Andrew had suggested some
> >>>>>> great
> >>>>>> release plan based time. But I fail to find the thread...)
> >>>>>>
> >>>>>> And for the 3.0.0 release, I think the new features should be
> decided
> >>>>>>>
> >>>>>> ASAP.
> >>>>>>
> >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> years
> >>>>>>>
> >>>>>> to
> >>>>
> >>>>> release a major version...
> >>>>>>>
> >>>>>> agreed!
> >>>>>>
> >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> As I volunteered to be the release manager for the 2.1 release line
> >>>>>>>
> >>>>>> so
> >>>>
> >>>>> let
> >>>>>>
> >>>>>>> me bring this up.
> >>>>>>>
> >>>>>>> For the 2.1 release line, I would like to define it as the 'real'
> 2.x
> >>>>>>> version of HBase. It should include the features which are reverted
> >>>>>>>
> >>>>>> or
> >>>>
> >>>>> disabled from 2.0.0 release, for example, serial replication, and in
> >>>>>>>
> >>>>>> memory
> >>>>>>
> >>>>>>> compaction. And also, the performance issues. And no more new
> >>>>>>>
> >>>>>> features.
> >>>>
> >>>>> If
> >>>>>>
> >>>>>>> no objections, I will start the release work soon.
> >>>>>>>
> >>>>>>> And for the 3.0.0 release, I think the new features should be
> decided
> >>>>>>>
> >>>>>> ASAP.
> >>>>>>
> >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> years
> >>>>>>>
> >>>>>> to
> >>>>
> >>>>> release a major version...
> >>>>>>>
> >>>>>>> For now, the new features
> >>>>>>> Synchronous replication
> >>>>>>> CCSMap
> >>>>>>> Backup
> >>>>>>> Spark connector(is it still active?)
> >>>>>>>
> >>>>>>> And I suggest that we include this:
> >>>>>>> The read path refactoring(HBASE-20525)
> >>>>>>>
> >>>>>>> Suggestions are welcomed.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by Josh Elser <el...@apache.org>.
Also, can you document 2.0 to 2.1? (even if there are no special steps) :)

Nice to see you continuing to push on 2.1, Duo!

On 6/3/18 10:09 PM, 张铎(Duo Zhang) wrote:
> Serial replication will be fine. And also I will do some work on document
> how to rolling upgrade from 1.x to 2.1.
> 
> 2018-06-04 9:55 GMT+08:00 Mike Drob <md...@apache.org>:
> 
>> Do you have an idea already of which features are making the cut?
>>
>> On Sun, Jun 3, 2018, 7:36 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>>
>>> Will cut the 2.1 branch tomorrow if no objections. The unfinished
>> features
>>> will be disabled by default or purged from branch-2.1 and target to 2.2
>>> release.
>>>
>>> 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>>>
>>>> Plan to cut branch-2.1 at the end of May. Will consider the status of
>> the
>>>> new features at that time to determine what will be released with 2.1.x
>>>> release line.
>>>>
>>>> 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
>>>>
>>>>> Big big big +1
>>>>>
>>>>> (Came in to say just this but you beat me to it :D)
>>>>>
>>>>>
>>>>> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
>>>>>
>>>>>> Let's do big features in 3.0.0 only.
>>>>>>
>>>>>> Ideally there will no big new features for a minor release, so that
>> we
>>>>>> can
>>>>>> move the stable pointer to newer minor versions quickly and retire
>> the
>>>>>> old
>>>>>> branches. It will be a nightmare if we have lots of active minor
>>> release
>>>>>> lines...
>>>>>>
>>>>>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
>>>>>>
>>>>>> Why 2.1 doesn't contatin synchronous replication? This can be a
>>>>>>> experiment
>>>>>>> feature in 2.1?
>>>>>>>
>>>>>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>>>>>>>
>>>>>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
>>>>>>>>
>>>>>>>> As I volunteered to be the release manager for the 2.1 release line
>>>>>>>>>>
>>>>>>>>> so
>>>>>>>
>>>>>>>> let
>>>>>>>>>
>>>>>>>>>> me bring this up.
>>>>>>>>>>
>>>>>>>>> +1 to Duo be RM of 2.1 release.
>>>>>>>>>
>>>>>>>>> disabled from 2.0.0 release, for example, serial replication, and
>> in
>>>>>>>>>>
>>>>>>>>> memory compaction
>>>>>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
>> policy
>>> is
>>>>>>>>> BASIC. (please correct me if I misunderstand something.)
>>>>>>>>>
>>>>>>>>> We disabled it by default in the end due to some performance
>>> issues...
>>>>>>>>
>>>>>>>>
>>>>>>>>> For the 2.1 release line, I would like to define it as the 'real'
>>> 2.x
>>>>>>>>>>
>>>>>>>>> Seems the release date between 2.0 and 2.1 will be very close. Is
>> it
>>>>>>>>> related to our new release plan? (IIRC, Andrew had suggested some
>>>>>>>>> great
>>>>>>>>> release plan based time. But I fail to find the thread...)
>>>>>>>>>
>>>>>>>>> And for the 3.0.0 release, I think the new features should be
>>> decided
>>>>>>>>>>
>>>>>>>>> ASAP.
>>>>>>>>>
>>>>>>>>>> We need to avoid the same thing happens again, i.e, spending 2
>>> years
>>>>>>>>>>
>>>>>>>>> to
>>>>>>>
>>>>>>>> release a major version...
>>>>>>>>>>
>>>>>>>>> agreed!
>>>>>>>>>
>>>>>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
>>> wrote:
>>>>>>>>>
>>>>>>>>>> As I volunteered to be the release manager for the 2.1 release
>> line
>>>>>>>>>>
>>>>>>>>> so
>>>>>>>
>>>>>>>> let
>>>>>>>>>
>>>>>>>>>> me bring this up.
>>>>>>>>>>
>>>>>>>>>> For the 2.1 release line, I would like to define it as the 'real'
>>> 2.x
>>>>>>>>>> version of HBase. It should include the features which are
>> reverted
>>>>>>>>>>
>>>>>>>>> or
>>>>>>>
>>>>>>>> disabled from 2.0.0 release, for example, serial replication, and
>> in
>>>>>>>>>>
>>>>>>>>> memory
>>>>>>>>>
>>>>>>>>>> compaction. And also, the performance issues. And no more new
>>>>>>>>>>
>>>>>>>>> features.
>>>>>>>
>>>>>>>> If
>>>>>>>>>
>>>>>>>>>> no objections, I will start the release work soon.
>>>>>>>>>>
>>>>>>>>>> And for the 3.0.0 release, I think the new features should be
>>> decided
>>>>>>>>>>
>>>>>>>>> ASAP.
>>>>>>>>>
>>>>>>>>>> We need to avoid the same thing happens again, i.e, spending 2
>>> years
>>>>>>>>>>
>>>>>>>>> to
>>>>>>>
>>>>>>>> release a major version...
>>>>>>>>>>
>>>>>>>>>> For now, the new features
>>>>>>>>>> Synchronous replication
>>>>>>>>>> CCSMap
>>>>>>>>>> Backup
>>>>>>>>>> Spark connector(is it still active?)
>>>>>>>>>>
>>>>>>>>>> And I suggest that we include this:
>>>>>>>>>> The read path refactoring(HBASE-20525)
>>>>>>>>>>
>>>>>>>>>> Suggestions are welcomed.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
> 

Re: On the 2.1.0 and 3.0.0 release

Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Serial replication will be fine. And also I will do some work on document
how to rolling upgrade from 1.x to 2.1.

2018-06-04 9:55 GMT+08:00 Mike Drob <md...@apache.org>:

> Do you have an idea already of which features are making the cut?
>
> On Sun, Jun 3, 2018, 7:36 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>
> > Will cut the 2.1 branch tomorrow if no objections. The unfinished
> features
> > will be disabled by default or purged from branch-2.1 and target to 2.2
> > release.
> >
> > 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> >
> > > Plan to cut branch-2.1 at the end of May. Will consider the status of
> the
> > > new features at that time to determine what will be released with 2.1.x
> > > release line.
> > >
> > > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> > >
> > >> Big big big +1
> > >>
> > >> (Came in to say just this but you beat me to it :D)
> > >>
> > >>
> > >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> > >>
> > >>> Let's do big features in 3.0.0 only.
> > >>>
> > >>> Ideally there will no big new features for a minor release, so that
> we
> > >>> can
> > >>> move the stable pointer to newer minor versions quickly and retire
> the
> > >>> old
> > >>> branches. It will be a nightmare if we have lots of active minor
> > release
> > >>> lines...
> > >>>
> > >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> > >>>
> > >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> > >>>> experiment
> > >>>> feature in 2.1?
> > >>>>
> > >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> > >>>>
> > >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
> > >>>>>
> > >>>>> As I volunteered to be the release manager for the 2.1 release line
> > >>>>>>>
> > >>>>>> so
> > >>>>
> > >>>>> let
> > >>>>>>
> > >>>>>>> me bring this up.
> > >>>>>>>
> > >>>>>> +1 to Duo be RM of 2.1 release.
> > >>>>>>
> > >>>>>> disabled from 2.0.0 release, for example, serial replication, and
> in
> > >>>>>>>
> > >>>>>> memory compaction
> > >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default
> policy
> > is
> > >>>>>> BASIC. (please correct me if I misunderstand something.)
> > >>>>>>
> > >>>>>> We disabled it by default in the end due to some performance
> > issues...
> > >>>>>
> > >>>>>
> > >>>>>> For the 2.1 release line, I would like to define it as the 'real'
> > 2.x
> > >>>>>>>
> > >>>>>> Seems the release date between 2.0 and 2.1 will be very close. Is
> it
> > >>>>>> related to our new release plan? (IIRC, Andrew had suggested some
> > >>>>>> great
> > >>>>>> release plan based time. But I fail to find the thread...)
> > >>>>>>
> > >>>>>> And for the 3.0.0 release, I think the new features should be
> > decided
> > >>>>>>>
> > >>>>>> ASAP.
> > >>>>>>
> > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > years
> > >>>>>>>
> > >>>>>> to
> > >>>>
> > >>>>> release a major version...
> > >>>>>>>
> > >>>>>> agreed!
> > >>>>>>
> > >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> > >>>>>>
> > >>>>>>> As I volunteered to be the release manager for the 2.1 release
> line
> > >>>>>>>
> > >>>>>> so
> > >>>>
> > >>>>> let
> > >>>>>>
> > >>>>>>> me bring this up.
> > >>>>>>>
> > >>>>>>> For the 2.1 release line, I would like to define it as the 'real'
> > 2.x
> > >>>>>>> version of HBase. It should include the features which are
> reverted
> > >>>>>>>
> > >>>>>> or
> > >>>>
> > >>>>> disabled from 2.0.0 release, for example, serial replication, and
> in
> > >>>>>>>
> > >>>>>> memory
> > >>>>>>
> > >>>>>>> compaction. And also, the performance issues. And no more new
> > >>>>>>>
> > >>>>>> features.
> > >>>>
> > >>>>> If
> > >>>>>>
> > >>>>>>> no objections, I will start the release work soon.
> > >>>>>>>
> > >>>>>>> And for the 3.0.0 release, I think the new features should be
> > decided
> > >>>>>>>
> > >>>>>> ASAP.
> > >>>>>>
> > >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> > years
> > >>>>>>>
> > >>>>>> to
> > >>>>
> > >>>>> release a major version...
> > >>>>>>>
> > >>>>>>> For now, the new features
> > >>>>>>> Synchronous replication
> > >>>>>>> CCSMap
> > >>>>>>> Backup
> > >>>>>>> Spark connector(is it still active?)
> > >>>>>>>
> > >>>>>>> And I suggest that we include this:
> > >>>>>>> The read path refactoring(HBASE-20525)
> > >>>>>>>
> > >>>>>>> Suggestions are welcomed.
> > >>>>>>>
> > >>>>>>> Thanks.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >
> >
>

Re: On the 2.1.0 and 3.0.0 release

Posted by Mike Drob <md...@apache.org>.
Do you have an idea already of which features are making the cut?

On Sun, Jun 3, 2018, 7:36 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Will cut the 2.1 branch tomorrow if no objections. The unfinished features
> will be disabled by default or purged from branch-2.1 and target to 2.2
> release.
>
> 2018-05-17 14:19 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>
> > Plan to cut branch-2.1 at the end of May. Will consider the status of the
> > new features at that time to determine what will be released with 2.1.x
> > release line.
> >
> > 2018-05-08 10:16 GMT+08:00 Josh Elser <el...@apache.org>:
> >
> >> Big big big +1
> >>
> >> (Came in to say just this but you beat me to it :D)
> >>
> >>
> >> On 5/7/18 12:07 AM, 张铎(Duo Zhang) wrote:
> >>
> >>> Let's do big features in 3.0.0 only.
> >>>
> >>> Ideally there will no big new features for a minor release, so that we
> >>> can
> >>> move the stable pointer to newer minor versions quickly and retire the
> >>> old
> >>> branches. It will be a nightmare if we have lots of active minor
> release
> >>> lines...
> >>>
> >>> 2018-05-07 14:53 GMT+08:00 Guanghao Zhang <zg...@gmail.com>:
> >>>
> >>> Why 2.1 doesn't contatin synchronous replication? This can be a
> >>>> experiment
> >>>> feature in 2.1?
> >>>>
> >>>> 2018-05-07 14:41 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> >>>>
> >>>> 2018-05-07 14:38 GMT+08:00 Chia-Ping Tsai <ch...@apache.org>:
> >>>>>
> >>>>> As I volunteered to be the release manager for the 2.1 release line
> >>>>>>>
> >>>>>> so
> >>>>
> >>>>> let
> >>>>>>
> >>>>>>> me bring this up.
> >>>>>>>
> >>>>>> +1 to Duo be RM of 2.1 release.
> >>>>>>
> >>>>>> disabled from 2.0.0 release, for example, serial replication, and in
> >>>>>>>
> >>>>>> memory compaction
> >>>>>> IIRC, in memory compaction is enabled in 2.0 and the default policy
> is
> >>>>>> BASIC. (please correct me if I misunderstand something.)
> >>>>>>
> >>>>>> We disabled it by default in the end due to some performance
> issues...
> >>>>>
> >>>>>
> >>>>>> For the 2.1 release line, I would like to define it as the 'real'
> 2.x
> >>>>>>>
> >>>>>> Seems the release date between 2.0 and 2.1 will be very close. Is it
> >>>>>> related to our new release plan? (IIRC, Andrew had suggested some
> >>>>>> great
> >>>>>> release plan based time. But I fail to find the thread...)
> >>>>>>
> >>>>>> And for the 3.0.0 release, I think the new features should be
> decided
> >>>>>>>
> >>>>>> ASAP.
> >>>>>>
> >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> years
> >>>>>>>
> >>>>>> to
> >>>>
> >>>>> release a major version...
> >>>>>>>
> >>>>>> agreed!
> >>>>>>
> >>>>>> On 2018/05/07 00:52:07, 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> As I volunteered to be the release manager for the 2.1 release line
> >>>>>>>
> >>>>>> so
> >>>>
> >>>>> let
> >>>>>>
> >>>>>>> me bring this up.
> >>>>>>>
> >>>>>>> For the 2.1 release line, I would like to define it as the 'real'
> 2.x
> >>>>>>> version of HBase. It should include the features which are reverted
> >>>>>>>
> >>>>>> or
> >>>>
> >>>>> disabled from 2.0.0 release, for example, serial replication, and in
> >>>>>>>
> >>>>>> memory
> >>>>>>
> >>>>>>> compaction. And also, the performance issues. And no more new
> >>>>>>>
> >>>>>> features.
> >>>>
> >>>>> If
> >>>>>>
> >>>>>>> no objections, I will start the release work soon.
> >>>>>>>
> >>>>>>> And for the 3.0.0 release, I think the new features should be
> decided
> >>>>>>>
> >>>>>> ASAP.
> >>>>>>
> >>>>>>> We need to avoid the same thing happens again, i.e, spending 2
> years
> >>>>>>>
> >>>>>> to
> >>>>
> >>>>> release a major version...
> >>>>>>>
> >>>>>>> For now, the new features
> >>>>>>> Synchronous replication
> >>>>>>> CCSMap
> >>>>>>> Backup
> >>>>>>> Spark connector(is it still active?)
> >>>>>>>
> >>>>>>> And I suggest that we include this:
> >>>>>>> The read path refactoring(HBASE-20525)
> >>>>>>>
> >>>>>>> Suggestions are welcomed.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>