I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
saw HBASE-7965 which suggests porting some major-ish features (table locks,
online merge) in to the apache 0.94 line.   We should chat about what we
want to do about new features and bringing them into stable versions (0.94
today) and in general criteria we use for future versions.

This is similar to the snapshots backport discussion and earlier backport
discussions.  Here's my understanding of  high level points we basically
agree upon.
* Backporting new features to the previous major version incurs more cost
when developing new features,  pushes back efforts on making the trunk
versions and reduces incentive to move to newer versions.
* Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
reasonable since they are generally less stable.
* Backporting new features to later version (0.9x.5, 0.9x.6) is less
reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
features).
* Backporting orthogonal features (snapshots) seems less risky than core
changing features
* An except: If multiple distributions declare intent to backport, it makes
sense to backport a feature. (snapshots for example).

Some new circumstances and discussion topics:
* We now have a dev branch (0.95) with looser compat requirements that we
could more readily release with dev/preview versions.  Shouldn't this
reduce the need to backport features to the apache stable branches?  Would
releases of these releases "replace" the 0.x.0 or 0.x.1 releases?
* For major features in later versions we should raise the bar on the
amount of testing probably be more explicit about what testing is done
(unit tests not suffcient, system testing stories/resports a requirement).
 Any other suggestions?

Jon.

--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

+1 to all of this.  Additionally, please keep in mind that when we backport
something now, we have to backport it to both 0.95 and 0.94.

- Dave
On Fri, Mar 1, 2013 at 8:31 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
> saw HBASE-7965 which suggests porting some major-ish features (table locks,
> online merge) in to the apache 0.94 line.   We should chat about what we
> want to do about new features and bringing them into stable versions (0.94
> today) and in general criteria we use for future versions.
>
> This is similar to the snapshots backport discussion and earlier backport
> discussions.  Here's my understanding of  high level points we basically
> agree upon.
> * Backporting new features to the previous major version incurs more cost
> when developing new features,  pushes back efforts on making the trunk
> versions and reduces incentive to move to newer versions.
> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> reasonable since they are generally less stable.
> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> features).
> * Backporting orthogonal features (snapshots) seems less risky than core
> changing features
> * An except: If multiple distributions declare intent to backport, it makes
> sense to backport a feature. (snapshots for example).
>
> Some new circumstances and discussion topics:
> * We now have a dev branch (0.95) with looser compat requirements that we
> could more readily release with dev/preview versions.  Shouldn't this
> reduce the need to backport features to the apache stable branches?  Would
> releases of these releases "replace" the 0.x.0 or 0.x.1 releases?
> * For major features in later versions we should raise the bar on the
> amount of testing probably be more explicit about what testing is done
> (unit tests not suffcient, system testing stories/resports a requirement).
>  Any other suggestions?
>
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]
>

This is an open source project, as long as there is a volunteer to backport a patch I see no problem with doing this.
The only thing we as the community should ensure is that it must be demonstrated that the patch does not destabilize the 0.94 code base; that has to be done on a case by case basis.
Also, there is no stable release of HBase other than 0.94 (0.95 is not stable, and we specifically state that it should not be used in production).

-- Lars

________________________________
 From: Jonathan Hsieh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, March 1, 2013 8:31 AM
Subject: [DISCUSS] More new feature backports to 0.94.
 
I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
saw HBASE-7965 which suggests porting some major-ish features (table locks,
online merge) in to the apache 0.94 line.   We should chat about what we
want to do about new features and bringing them into stable versions (0.94
today) and in general criteria we use for future versions.

This is similar to the snapshots backport discussion and earlier backport
discussions.  Here's my understanding of  high level points we basically
agree upon.
* Backporting new features to the previous major version incurs more cost
when developing new features,  pushes back efforts on making the trunk
versions and reduces incentive to move to newer versions.
* Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
reasonable since they are generally less stable.
* Backporting new features to later version (0.9x.5, 0.9x.6) is less
reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
features).
* Backporting orthogonal features (snapshots) seems less risky than core
changing features
* An except: If multiple distributions declare intent to backport, it makes
sense to backport a feature. (snapshots for example).

Some new circumstances and discussion topics:
* We now have a dev branch (0.95) with looser compat requirements that we
could more readily release with dev/preview versions.  Shouldn't this
reduce the need to backport features to the apache stable branches?  Would
releases of these releases "replace" the 0.x.0 or 0.x.1 releases?
* For major features in later versions we should raise the bar on the
amount of testing probably be more explicit about what testing is done
(unit tests not suffcient, system testing stories/resports a requirement).
Any other suggestions?

Jon.

--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

I'm worried about users who are starting to use 0.94.x.  If they have a bug
in that version, and it's fixed or they submit a patch to fix it.  Then
they should have a version to upgrade to that includes that bug fix and
doesn't include other new features.   I don't think that many people will
want to upgrade their production database to new feature and code when
trying to fix a bug.

Something like http://www.postgresql.org/support/versioning/ seems very
similar to what I would envision.  Only major versions contain new
features.  We're not at a place that the community sees a 1.0.0 as
realistic so we don't have the first number to play with.  I don't think
that changes the fact that the last number should in my opinion be reserved
for patch releases.
On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> This is an open source project, as long as there is a volunteer to
> backport a patch I see no problem with doing this.
> The only thing we as the community should ensure is that it must be
> demonstrated that the patch does not destabilize the 0.94 code base; that
> has to be done on a case by case basis.
>
>
> Also, there is no stable release of HBase other than 0.94 (0.95 is not
> stable, and we specifically state that it should not be used in production).
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, March 1, 2013 8:31 AM
> Subject: [DISCUSS] More new feature backports to 0.94.
>
> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
> saw HBASE-7965 which suggests porting some major-ish features (table locks,
> online merge) in to the apache 0.94 line.   We should chat about what we
> want to do about new features and bringing them into stable versions (0.94
> today) and in general criteria we use for future versions.
>
> This is similar to the snapshots backport discussion and earlier backport
> discussions.  Here's my understanding of  high level points we basically
> agree upon.
> * Backporting new features to the previous major version incurs more cost
> when developing new features,  pushes back efforts on making the trunk
> versions and reduces incentive to move to newer versions.
> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> reasonable since they are generally less stable.
> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> features).
> * Backporting orthogonal features (snapshots) seems less risky than core
> changing features
> * An except: If multiple distributions declare intent to backport, it makes
> sense to backport a feature. (snapshots for example).
>
> Some new circumstances and discussion topics:
> * We now have a dev branch (0.95) with looser compat requirements that we
> could more readily release with dev/preview versions.  Shouldn't this
> reduce the need to backport features to the apache stable branches?  Would
> releases of these releases "replace" the 0.x.0 or 0.x.1 releases?
> * For major features in later versions we should raise the bar on the
> amount of testing probably be more explicit about what testing is done
> (unit tests not suffcient, system testing stories/resports a requirement).
> Any other suggestions?
>
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]
>

I think we are basically agreeing -- my primary concern is bringing new
features in vital paths introduces more risk, I'd rather not backport major
new features unless we achieve a higher level of assurance through system
and basic fault injection testing.

For the three current examples -- snapshots, zk table locks, online merge
-- I actually would prefer not including any in apache 0.94.  Of the bunch,
I feel the table locks are the most risky since it affects vital paths a
user must use,  where as snapshots and online merge are features that a
user could choose to use but does not necessarily have to use.  I'll voice
my concerns, reason for concerns, and justifications on the individual
jiras.

I do feel that new features being in a dev/preview release like 0.95 aligns
well and doesn't create situations where different versions have different
feature sets.  New features should be introduced and hardened in a
dev/preview version, and the turn into the production ready versions after
they've been proven out a bit.

Jon.

On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> This is an open source project, as long as there is a volunteer to
> backport a patch I see no problem with doing this.
> The only thing we as the community should ensure is that it must be
> demonstrated that the patch does not destabilize the 0.94 code base; that
> has to be done on a case by case basis.
>
>
> Also, there is no stable release of HBase other than 0.94 (0.95 is not
> stable, and we specifically state that it should not be used in production).
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, March 1, 2013 8:31 AM
> Subject: [DISCUSS] More new feature backports to 0.94.
>
> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
> saw HBASE-7965 which suggests porting some major-ish features (table locks,
> online merge) in to the apache 0.94 line.   We should chat about what we
> want to do about new features and bringing them into stable versions (0.94
> today) and in general criteria we use for future versions.
>
> This is similar to the snapshots backport discussion and earlier backport
> discussions.  Here's my understanding of  high level points we basically
> agree upon.
> * Backporting new features to the previous major version incurs more cost
> when developing new features,  pushes back efforts on making the trunk
> versions and reduces incentive to move to newer versions.
> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> reasonable since they are generally less stable.
> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> features).
> * Backporting orthogonal features (snapshots) seems less risky than core
> changing features
> * An except: If multiple distributions declare intent to backport, it makes
> sense to backport a feature. (snapshots for example).
>
> Some new circumstances and discussion topics:
> * We now have a dev branch (0.95) with looser compat requirements that we
> could more readily release with dev/preview versions.  Shouldn't this
> reduce the need to backport features to the apache stable branches?  Would
> releases of these releases "replace" the 0.x.0 or 0.x.1 releases?
> * For major features in later versions we should raise the bar on the
> amount of testing probably be more explicit about what testing is done
> (unit tests not suffcient, system testing stories/resports a requirement).
> Any other suggestions?
>
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]
>

--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

I also think also that new features need to go in new versions only
and try to avoid backporting them.. Else if we keep adding new
features in previous versions, we might have to keep adding bug fixes
because of those features and it's a never ending story.

But as Elliott is saying, we need to push the fixes in all the branchs
and not only the trunk to not force people to migrate to new major
releases to get some bugs fixed.

The postgresql versionning policy is nice. But I'm not sure we should
keep 4 versions running. 4 version will mean we still need to backport
fixes to 0.90.x even when 0.96 will be out. I'm not sure it's
realistic since there is to much differences between all those
versions. I will say 2 to 3 is the max. Like when a version is recent
we can keep 3 versions going, but when the versions is not to its
x.x.4 ou x.x.5, it's supposed to be stable enought and we can think
about stopping the support for the 3 versions and move to 2.

With today versions that will mean that we support 0.92.x and 0.94.x
since we are at 0.94.5. And we will continue to support 0.92.x until
0.96 is up to 0.96.4.

Just my opinion.

2013/3/1 Elliott Clark <[EMAIL PROTECTED]>:
> I'm worried about users who are starting to use 0.94.x.  If they have a bug
> in that version, and it's fixed or they submit a patch to fix it.  Then
> they should have a version to upgrade to that includes that bug fix and
> doesn't include other new features.   I don't think that many people will
> want to upgrade their production database to new feature and code when
> trying to fix a bug.
>
> Something like http://www.postgresql.org/support/versioning/ seems very
> similar to what I would envision.  Only major versions contain new
> features.  We're not at a place that the community sees a 1.0.0 as
> realistic so we don't have the first number to play with.  I don't think
> that changes the fact that the last number should in my opinion be reserved
> for patch releases.
>
>
> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
>> This is an open source project, as long as there is a volunteer to
>> backport a patch I see no problem with doing this.
>> The only thing we as the community should ensure is that it must be
>> demonstrated that the patch does not destabilize the 0.94 code base; that
>> has to be done on a case by case basis.
>>
>>
>> Also, there is no stable release of HBase other than 0.94 (0.95 is not
>> stable, and we specifically state that it should not be used in production).
>>
>> -- Lars
>>
>>
>>
>> ________________________________
>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Sent: Friday, March 1, 2013 8:31 AM
>> Subject: [DISCUSS] More new feature backports to 0.94.
>>
>> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
>> saw HBASE-7965 which suggests porting some major-ish features (table locks,
>> online merge) in to the apache 0.94 line.   We should chat about what we
>> want to do about new features and bringing them into stable versions (0.94
>> today) and in general criteria we use for future versions.
>>
>> This is similar to the snapshots backport discussion and earlier backport
>> discussions.  Here's my understanding of  high level points we basically
>> agree upon.
>> * Backporting new features to the previous major version incurs more cost
>> when developing new features,  pushes back efforts on making the trunk
>> versions and reduces incentive to move to newer versions.
>> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
>> reasonable since they are generally less stable.
>> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
>> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
>> features).
>> * Backporting orthogonal features (snapshots) seems less risky than core
>> changing features
>> * An except: If multiple distributions declare intent to backport, it makes
>> sense to backport a feature. (snapshots for example).

I think we have discussed this before, and your concerns are valid.

In the snapshot backporting discussions, I have proposed to do fork 94, and
add snapshots on top of it, and make a release called 0.95 (0.95 wasn't
being used back then). The conclusion from those discussions was that, if I
remember correctly, that if there will be significant testing from HW+C,
then we might be ok with the backport. The key point from those discussions
was that since 96 is so late, we only have 94 as the only stable target
that features like table locks, snapshots, merge, etc (which are orthogonal
to wire compat) can be delivered to users in a timely maner. The current
situation with 94 is an exception, rather than the norm, because we could
not deliver stable releases for the new features for such a long time.
Since 96 is still at least 2-3 months ahead, if we want to deliver
snapshots, table locks, etc, 94 is the place.

The only alternative I can see is to fork 94 branch, and add the new
features there. We can call it 94-snapshots branch, and have releases from
there, as well as releases from plain 94.

Enis
On Fri, Mar 1, 2013 at 3:12 PM, Jean-Marc Spaggiari <[EMAIL PROTECTED]
> wrote:

> I also think also that new features need to go in new versions only
> and try to avoid backporting them.. Else if we keep adding new
> features in previous versions, we might have to keep adding bug fixes
> because of those features and it's a never ending story.
>
> But as Elliott is saying, we need to push the fixes in all the branchs
> and not only the trunk to not force people to migrate to new major
> releases to get some bugs fixed.
>
> The postgresql versionning policy is nice. But I'm not sure we should
> keep 4 versions running. 4 version will mean we still need to backport
> fixes to 0.90.x even when 0.96 will be out. I'm not sure it's
> realistic since there is to much differences between all those
> versions. I will say 2 to 3 is the max. Like when a version is recent
> we can keep 3 versions going, but when the versions is not to its
> x.x.4 ou x.x.5, it's supposed to be stable enought and we can think
> about stopping the support for the 3 versions and move to 2.
>
> With today versions that will mean that we support 0.92.x and 0.94.x
> since we are at 0.94.5. And we will continue to support 0.92.x until
> 0.96 is up to 0.96.4.
>
> Just my opinion.
>
> 2013/3/1 Elliott Clark <[EMAIL PROTECTED]>:
> > I'm worried about users who are starting to use 0.94.x.  If they have a
> bug
> > in that version, and it's fixed or they submit a patch to fix it.  Then
> > they should have a version to upgrade to that includes that bug fix and
> > doesn't include other new features.   I don't think that many people will
> > want to upgrade their production database to new feature and code when
> > trying to fix a bug.
> >
> > Something like http://www.postgresql.org/support/versioning/ seems very
> > similar to what I would envision.  Only major versions contain new
> > features.  We're not at a place that the community sees a 1.0.0 as
> > realistic so we don't have the first number to play with.  I don't think
> > that changes the fact that the last number should in my opinion be
> reserved
> > for patch releases.
> >
> >
> > On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> >
> >> This is an open source project, as long as there is a volunteer to
> >> backport a patch I see no problem with doing this.
> >> The only thing we as the community should ensure is that it must be
> >> demonstrated that the patch does not destabilize the 0.94 code base;
> that
> >> has to be done on a case by case basis.
> >>
> >>
> >> Also, there is no stable release of HBase other than 0.94 (0.95 is not
> >> stable, and we specifically state that it should not be used in
> production).
> >>
> >> -- Lars
> >>
> >>
> >>
> >> ________________________________
> >>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> >> To: [EMAIL PROTECTED]
> >> Sent: Friday, March 1, 2013 8:31 AM

So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we have three options:
1. Backport new features to 0.94 as we see fit as long as we do not destabilize 0.94.
2. Declare a certain point release (0.94.6 looks like a good candidate) as a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6 tag) and than create 0.94.6.x fix only releases. I would volunteer to maintain a 0.94.6 branch in addition to the 0.94 branch.
3. Categorically do not backport new features into 0.94 and defer to 0.95.

I'd be +1 on option #1 and #2, and -1 on option #3.

-- Lars

________________________________
 From: Jonathan Hsieh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
Sent: Friday, March 1, 2013 3:11 PM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 
I think we are basically agreeing -- my primary concern is bringing new
features in vital paths introduces more risk, I'd rather not backport major
new features unless we achieve a higher level of assurance through system
and basic fault injection testing.

For the three current examples -- snapshots, zk table locks, online merge
-- I actually would prefer not including any in apache 0.94.  Of the bunch,
I feel the table locks are the most risky since it affects vital paths a
user must use,  where as snapshots and online merge are features that a
user could choose to use but does not necessarily have to use.  I'll voice
my concerns, reason for concerns, and justifications on the individual
jiras.

I do feel that new features being in a dev/preview release like 0.95 aligns
well and doesn't create situations where different versions have different
feature sets.  New features should be introduced and hardened in a
dev/preview version, and the turn into the production ready versions after
they've been proven out a bit.

Jon.

On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> This is an open source project, as long as there is a volunteer to
> backport a patch I see no problem with doing this.
> The only thing we as the community should ensure is that it must be
> demonstrated that the patch does not destabilize the 0.94 code base; that
> has to be done on a case by case basis.
>
>
> Also, there is no stable release of HBase other than 0.94 (0.95 is not
> stable, and we specifically state that it should not be used in production).
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, March 1, 2013 8:31 AM
> Subject: [DISCUSS] More new feature backports to 0.94.
>
> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
> saw HBASE-7965 which suggests porting some major-ish features (table locks,
> online merge) in to the apache 0.94 line.   We should chat about what we
> want to do about new features and bringing them into stable versions (0.94
> today) and in general criteria we use for future versions.
>
> This is similar to the snapshots backport discussion and earlier backport
> discussions.  Here's my understanding of  high level points we basically
> agree upon.
> * Backporting new features to the previous major version incurs more cost
> when developing new features,  pushes back efforts on making the trunk
> versions and reduces incentive to move to newer versions.
> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> reasonable since they are generally less stable.
> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> features).
> * Backporting orthogonal features (snapshots) seems less risky than core
> changing features
> * An except: If multiple distributions declare intent to backport, it makes
> sense to backport a feature. (snapshots for example).
>
> Some new circumstances and discussion topics:
> * We now have a dev branch (0.95) with looser compat requirements that we
> could more readily release with dev/preview versions.  Shouldn't this

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

Thanks Lars, I think it is a good listing of the options we have.

I'll be +1 for #1 and #2, with #1 being a preference.

Enis
On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
> have three options:
> 1. Backport new features to 0.94 as we see fit as long as we do not
> destabilize 0.94.
> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> tag) and than create 0.94.6.x fix only releases. I would volunteer to
> maintain a 0.94.6 branch in addition to the 0.94 branch.
> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>
> I'd be +1 on option #1 and #2, and -1 on option #3.
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
> Sent: Friday, March 1, 2013 3:11 PM
> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>
> I think we are basically agreeing -- my primary concern is bringing new
> features in vital paths introduces more risk, I'd rather not backport major
> new features unless we achieve a higher level of assurance through system
> and basic fault injection testing.
>
> For the three current examples -- snapshots, zk table locks, online merge
> -- I actually would prefer not including any in apache 0.94.  Of the bunch,
> I feel the table locks are the most risky since it affects vital paths a
> user must use,  where as snapshots and online merge are features that a
> user could choose to use but does not necessarily have to use.  I'll voice
> my concerns, reason for concerns, and justifications on the individual
> jiras.
>
> I do feel that new features being in a dev/preview release like 0.95 aligns
> well and doesn't create situations where different versions have different
> feature sets.  New features should be introduced and hardened in a
> dev/preview version, and the turn into the production ready versions after
> they've been proven out a bit.
>
> Jon.
>
> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > This is an open source project, as long as there is a volunteer to
> > backport a patch I see no problem with doing this.
> > The only thing we as the community should ensure is that it must be
> > demonstrated that the patch does not destabilize the 0.94 code base; that
> > has to be done on a case by case basis.
> >
> >
> > Also, there is no stable release of HBase other than 0.94 (0.95 is not
> > stable, and we specifically state that it should not be used in
> production).
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> >  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Sent: Friday, March 1, 2013 8:31 AM
> > Subject: [DISCUSS] More new feature backports to 0.94.
> >
> > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and
> also
> > saw HBASE-7965 which suggests porting some major-ish features (table
> locks,
> > online merge) in to the apache 0.94 line.   We should chat about what we
> > want to do about new features and bringing them into stable versions
> (0.94
> > today) and in general criteria we use for future versions.
> >
> > This is similar to the snapshots backport discussion and earlier backport
> > discussions.  Here's my understanding of  high level points we basically
> > agree upon.
> > * Backporting new features to the previous major version incurs more cost
> > when developing new features,  pushes back efforts on making the trunk
> > versions and reduces incentive to move to newer versions.
> > * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> > reasonable since they are generally less stable.
> > * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> > reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> > features).

+1 on option #1.
+0 on option #2.

On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
> have three options:
> 1. Backport new features to 0.94 as we see fit as long as we do not
> destabilize 0.94.
> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> tag) and than create 0.94.6.x fix only releases. I would volunteer to
> maintain a 0.94.6 branch in addition to the 0.94 branch.
> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>
> I'd be +1 on option #1 and #2, and -1 on option #3.
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
> Sent: Friday, March 1, 2013 3:11 PM
> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>
> I think we are basically agreeing -- my primary concern is bringing new
> features in vital paths introduces more risk, I'd rather not backport major
> new features unless we achieve a higher level of assurance through system
> and basic fault injection testing.
>
> For the three current examples -- snapshots, zk table locks, online merge
> -- I actually would prefer not including any in apache 0.94.  Of the bunch,
> I feel the table locks are the most risky since it affects vital paths a
> user must use,  where as snapshots and online merge are features that a
> user could choose to use but does not necessarily have to use.  I'll voice
> my concerns, reason for concerns, and justifications on the individual
> jiras.
>
> I do feel that new features being in a dev/preview release like 0.95 aligns
> well and doesn't create situations where different versions have different
> feature sets.  New features should be introduced and hardened in a
> dev/preview version, and the turn into the production ready versions after
> they've been proven out a bit.
>
> Jon.
>
> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > This is an open source project, as long as there is a volunteer to
> > backport a patch I see no problem with doing this.
> > The only thing we as the community should ensure is that it must be
> > demonstrated that the patch does not destabilize the 0.94 code base; that
> > has to be done on a case by case basis.
> >
> >
> > Also, there is no stable release of HBase other than 0.94 (0.95 is not
> > stable, and we specifically state that it should not be used in
> production).
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> >  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Sent: Friday, March 1, 2013 8:31 AM
> > Subject: [DISCUSS] More new feature backports to 0.94.
> >
> > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and
> also
> > saw HBASE-7965 which suggests porting some major-ish features (table
> locks,
> > online merge) in to the apache 0.94 line.   We should chat about what we
> > want to do about new features and bringing them into stable versions
> (0.94
> > today) and in general criteria we use for future versions.
> >
> > This is similar to the snapshots backport discussion and earlier backport
> > discussions.  Here's my understanding of  high level points we basically
> > agree upon.
> > * Backporting new features to the previous major version incurs more cost
> > when developing new features,  pushes back efforts on making the trunk
> > versions and reduces incentive to move to newer versions.
> > * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> > reasonable since they are generally less stable.
> > * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> > reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> > features).
> > * Backporting orthogonal features (snapshots) seems less risky than core
> > changing features

Hi Lars, #2, does it mean you will stop back-porting the new features
when it will become a "long-term" release? If so, I'm for option #2...

JM

In your option
2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> Thanks Lars, I think it is a good listing of the options we have.
>
> I'll be +1 for #1 and #2, with #1 being a preference.
>
> Enis
>
>
> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
>> have three options:
>> 1. Backport new features to 0.94 as we see fit as long as we do not
>> destabilize 0.94.
>> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>>
>> I'd be +1 on option #1 and #2, and -1 on option #3.
>>
>> -- Lars
>>
>>
>>
>> ________________________________
>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> Sent: Friday, March 1, 2013 3:11 PM
>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>>
>> I think we are basically agreeing -- my primary concern is bringing new
>> features in vital paths introduces more risk, I'd rather not backport major
>> new features unless we achieve a higher level of assurance through system
>> and basic fault injection testing.
>>
>> For the three current examples -- snapshots, zk table locks, online merge
>> -- I actually would prefer not including any in apache 0.94.  Of the bunch,
>> I feel the table locks are the most risky since it affects vital paths a
>> user must use,  where as snapshots and online merge are features that a
>> user could choose to use but does not necessarily have to use.  I'll voice
>> my concerns, reason for concerns, and justifications on the individual
>> jiras.
>>
>> I do feel that new features being in a dev/preview release like 0.95 aligns
>> well and doesn't create situations where different versions have different
>> feature sets.  New features should be introduced and hardened in a
>> dev/preview version, and the turn into the production ready versions after
>> they've been proven out a bit.
>>
>> Jon.
>>
>> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>
>> > This is an open source project, as long as there is a volunteer to
>> > backport a patch I see no problem with doing this.
>> > The only thing we as the community should ensure is that it must be
>> > demonstrated that the patch does not destabilize the 0.94 code base; that
>> > has to be done on a case by case basis.
>> >
>> >
>> > Also, there is no stable release of HBase other than 0.94 (0.95 is not
>> > stable, and we specifically state that it should not be used in
>> production).
>> >
>> > -- Lars
>> >
>> >
>> >
>> > ________________________________
>> >  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> > To: [EMAIL PROTECTED]
>> > Sent: Friday, March 1, 2013 8:31 AM
>> > Subject: [DISCUSS] More new feature backports to 0.94.
>> >
>> > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and
>> also
>> > saw HBASE-7965 which suggests porting some major-ish features (table
>> locks,
>> > online merge) in to the apache 0.94 line.   We should chat about what we
>> > want to do about new features and bringing them into stable versions
>> (0.94
>> > today) and in general criteria we use for future versions.
>> >
>> > This is similar to the snapshots backport discussion and earlier backport
>> > discussions.  Here's my understanding of  high level points we basically
>> > agree upon.
>> > * Backporting new features to the previous major version incurs more cost
>> > when developing new features,  pushes back efforts on making the trunk
>> > versions and reduces incentive to move to newer versions.

Yes. That's the idea.

#1 does not mean that we "milli-vanilli" back port random things into 0.94. We'll weigh the pros and the risks and decide based on that.

My personal preference is indeed option #1, but as I said I'd volunteer to make #2 happen.

-- Lars

Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:

>Hi Lars, #2, does it mean you will stop back-porting the new features
>when it will become a "long-term" release? If so, I'm for option #2...
>
>JM
>
>In your option
>2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>> Thanks Lars, I think it is a good listing of the options we have.
>>
>> I'll be +1 for #1 and #2, with #1 being a preference.
>>
>> Enis
>>
>>
>> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>
>>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
>>> have three options:
>>> 1. Backport new features to 0.94 as we see fit as long as we do not
>>> destabilize 0.94.
>>> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
>>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>>> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>>>
>>> I'd be +1 on option #1 and #2, and -1 on option #3.
>>>
>>> -- Lars
>>>
>>>
>>>
>>> ________________________________
>>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>>> Sent: Friday, March 1, 2013 3:11 PM
>>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>>>
>>> I think we are basically agreeing -- my primary concern is bringing new
>>> features in vital paths introduces more risk, I'd rather not backport major
>>> new features unless we achieve a higher level of assurance through system
>>> and basic fault injection testing.
>>>
>>> For the three current examples -- snapshots, zk table locks, online merge
>>> -- I actually would prefer not including any in apache 0.94.  Of the bunch,
>>> I feel the table locks are the most risky since it affects vital paths a
>>> user must use,  where as snapshots and online merge are features that a
>>> user could choose to use but does not necessarily have to use.  I'll voice
>>> my concerns, reason for concerns, and justifications on the individual
>>> jiras.
>>>
>>> I do feel that new features being in a dev/preview release like 0.95 aligns
>>> well and doesn't create situations where different versions have different
>>> feature sets.  New features should be introduced and hardened in a
>>> dev/preview version, and the turn into the production ready versions after
>>> they've been proven out a bit.
>>>
>>> Jon.
>>>
>>> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>>
>>> > This is an open source project, as long as there is a volunteer to
>>> > backport a patch I see no problem with doing this.
>>> > The only thing we as the community should ensure is that it must be
>>> > demonstrated that the patch does not destabilize the 0.94 code base; that
>>> > has to be done on a case by case basis.
>>> >
>>> >
>>> > Also, there is no stable release of HBase other than 0.94 (0.95 is not
>>> > stable, and we specifically state that it should not be used in
>>> production).
>>> >
>>> > -- Lars
>>> >
>>> >
>>> >
>>> > ________________________________
>>> >  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>>> > To: [EMAIL PROTECTED]
>>> > Sent: Friday, March 1, 2013 8:31 AM
>>> > Subject: [DISCUSS] More new feature backports to 0.94.
>>> >
>>> > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and
>>> also
>>> > saw HBASE-7965 which suggests porting some major-ish features (table
>>> locks,
>>> > online merge) in to the apache 0.94 line.   We should chat about what we
>>> > want to do about new features and bringing them into stable versions
>>> (0.94
>>> > today) and in general criteria we use for future versions.

BTW are you concerned about any specific back port we did in the past? So far we have not seen any destabilization in any of the 0.94 releases.

Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:

>Hi Lars, #2, does it mean you will stop back-porting the new features
>when it will become a "long-term" release? If so, I'm for option #2...
>
>JM
>
>In your option
>2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>> Thanks Lars, I think it is a good listing of the options we have.
>>
>> I'll be +1 for #1 and #2, with #1 being a preference.
>>
>> Enis
>>
>>
>> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>
>>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
>>> have three options:
>>> 1. Backport new features to 0.94 as we see fit as long as we do not
>>> destabilize 0.94.
>>> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
>>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>>> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>>>
>>> I'd be +1 on option #1 and #2, and -1 on option #3.
>>>
>>> -- Lars
>>>
>>>
>>>
>>> ________________________________
>>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>>> Sent: Friday, March 1, 2013 3:11 PM
>>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>>>
>>> I think we are basically agreeing -- my primary concern is bringing new
>>> features in vital paths introduces more risk, I'd rather not backport major
>>> new features unless we achieve a higher level of assurance through system
>>> and basic fault injection testing.
>>>
>>> For the three current examples -- snapshots, zk table locks, online merge
>>> -- I actually would prefer not including any in apache 0.94.  Of the bunch,
>>> I feel the table locks are the most risky since it affects vital paths a
>>> user must use,  where as snapshots and online merge are features that a
>>> user could choose to use but does not necessarily have to use.  I'll voice
>>> my concerns, reason for concerns, and justifications on the individual
>>> jiras.
>>>
>>> I do feel that new features being in a dev/preview release like 0.95 aligns
>>> well and doesn't create situations where different versions have different
>>> feature sets.  New features should be introduced and hardened in a
>>> dev/preview version, and the turn into the production ready versions after
>>> they've been proven out a bit.
>>>
>>> Jon.
>>>
>>> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>>
>>> > This is an open source project, as long as there is a volunteer to
>>> > backport a patch I see no problem with doing this.
>>> > The only thing we as the community should ensure is that it must be
>>> > demonstrated that the patch does not destabilize the 0.94 code base; that
>>> > has to be done on a case by case basis.
>>> >
>>> >
>>> > Also, there is no stable release of HBase other than 0.94 (0.95 is not
>>> > stable, and we specifically state that it should not be used in
>>> production).
>>> >
>>> > -- Lars
>>> >
>>> >
>>> >
>>> > ________________________________
>>> >  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>>> > To: [EMAIL PROTECTED]
>>> > Sent: Friday, March 1, 2013 8:31 AM
>>> > Subject: [DISCUSS] More new feature backports to 0.94.
>>> >
>>> > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and
>>> also
>>> > saw HBASE-7965 which suggests porting some major-ish features (table
>>> locks,
>>> > online merge) in to the apache 0.94 line.   We should chat about what we
>>> > want to do about new features and bringing them into stable versions
>>> (0.94
>>> > today) and in general criteria we use for future versions.
>>> >
>>> > This is similar to the snapshots backport discussion and earlier backport
>>> > discussions.  Here's my understanding of  high level points we basically

I think the current way of risk vs rewards analysis is working well. We
will just continue doing that on a case by case basis, discussing the
implications on individual issues.

On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]> wrote:

> BTW are you concerned about any specific back port we did in the past? So
> far we have not seen any destabilization in any of the 0.94 releases.
>
> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
>
> >Hi Lars, #2, does it mean you will stop back-porting the new features
> >when it will become a "long-term" release? If so, I'm for option #2...
> >
> >JM
> >
> >In your option
> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> >> Thanks Lars, I think it is a good listing of the options we have.
> >>
> >> I'll be +1 for #1 and #2, with #1 being a preference.
> >>
> >> Enis
> >>
> >>
> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> >>
> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2)
> we
> >>> have three options:
> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
> >>> destabilize 0.94.
> >>> 2. Declare a certain point release (0.94.6 looks like a good
> candidate) as
> >>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
> >>> 3. Categorically do not backport new features into 0.94 and defer to
> 0.95.
> >>>
> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
> >>>
> >>> -- Lars
> >>>
> >>>
> >>>
> >>> ________________________________
> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
> >>> Sent: Friday, March 1, 2013 3:11 PM
> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
> >>>
> >>> I think we are basically agreeing -- my primary concern is bringing new
> >>> features in vital paths introduces more risk, I'd rather not backport
> major
> >>> new features unless we achieve a higher level of assurance through
> system
> >>> and basic fault injection testing.
> >>>
> >>> For the three current examples -- snapshots, zk table locks, online
> merge
> >>> -- I actually would prefer not including any in apache 0.94.  Of the
> bunch,
> >>> I feel the table locks are the most risky since it affects vital paths
> a
> >>> user must use,  where as snapshots and online merge are features that a
> >>> user could choose to use but does not necessarily have to use.  I'll
> voice
> >>> my concerns, reason for concerns, and justifications on the individual
> >>> jiras.
> >>>
> >>> I do feel that new features being in a dev/preview release like 0.95
> aligns
> >>> well and doesn't create situations where different versions have
> different
> >>> feature sets.  New features should be introduced and hardened in a
> >>> dev/preview version, and the turn into the production ready versions
> after
> >>> they've been proven out a bit.
> >>>
> >>> Jon.
> >>>
> >>> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]>
> wrote:
> >>>
> >>> > This is an open source project, as long as there is a volunteer to
> >>> > backport a patch I see no problem with doing this.
> >>> > The only thing we as the community should ensure is that it must be
> >>> > demonstrated that the patch does not destabilize the 0.94 code base;
> that
> >>> > has to be done on a case by case basis.
> >>> >
> >>> >
> >>> > Also, there is no stable release of HBase other than 0.94 (0.95 is
> not
> >>> > stable, and we specifically state that it should not be used in
> >>> production).
> >>> >
> >>> > -- Lars
> >>> >
> >>> >
> >>> >
> >>> > ________________________________
> >>> >  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> >>> > To: [EMAIL PROTECTED]
> >>> > Sent: Friday, March 1, 2013 8:31 AM
> >>> > Subject: [DISCUSS] More new feature backports to 0.94.
> >>> >
> >>> > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and

@Lars: No, not any concern about anything already backported. Just a
preference to #2 because it seems to make things more stable and
easier to manage. New feature = new release. Given new sub-releases
are for fixes and improvements, but not new features. Also, if we
backport a feature in one or many previous releases, we will have to
backport also all the fixes each time there will be an issue. So we
will have more maintenant work on previous releases.

2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> I think the current way of risk vs rewards analysis is working well. We
> will just continue doing that on a case by case basis, discussing the
> implications on individual issues.
>
>
>
> On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]> wrote:
>
>> BTW are you concerned about any specific back port we did in the past? So
>> far we have not seen any destabilization in any of the 0.94 releases.
>>
>> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
>>
>> >Hi Lars, #2, does it mean you will stop back-porting the new features
>> >when it will become a "long-term" release? If so, I'm for option #2...
>> >
>> >JM
>> >
>> >In your option
>> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>> >> Thanks Lars, I think it is a good listing of the options we have.
>> >>
>> >> I'll be +1 for #1 and #2, with #1 being a preference.
>> >>
>> >> Enis
>> >>
>> >>
>> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2)
>> we
>> >>> have three options:
>> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
>> >>> destabilize 0.94.
>> >>> 2. Declare a certain point release (0.94.6 looks like a good
>> candidate) as
>> >>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> >>> 3. Categorically do not backport new features into 0.94 and defer to
>> 0.95.
>> >>>
>> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
>> >>>
>> >>> -- Lars
>> >>>
>> >>>
>> >>>
>> >>> ________________________________
>> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> >>> Sent: Friday, March 1, 2013 3:11 PM
>> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>> >>>
>> >>> I think we are basically agreeing -- my primary concern is bringing new
>> >>> features in vital paths introduces more risk, I'd rather not backport
>> major
>> >>> new features unless we achieve a higher level of assurance through
>> system
>> >>> and basic fault injection testing.
>> >>>
>> >>> For the three current examples -- snapshots, zk table locks, online
>> merge
>> >>> -- I actually would prefer not including any in apache 0.94.  Of the
>> bunch,
>> >>> I feel the table locks are the most risky since it affects vital paths
>> a
>> >>> user must use,  where as snapshots and online merge are features that a
>> >>> user could choose to use but does not necessarily have to use.  I'll
>> voice
>> >>> my concerns, reason for concerns, and justifications on the individual
>> >>> jiras.
>> >>>
>> >>> I do feel that new features being in a dev/preview release like 0.95
>> aligns
>> >>> well and doesn't create situations where different versions have
>> different
>> >>> feature sets.  New features should be introduced and hardened in a
>> >>> dev/preview version, and the turn into the production ready versions
>> after
>> >>> they've been proven out a bit.
>> >>>
>> >>> Jon.
>> >>>
>> >>> On Fri, Mar 1, 2013 at 11:00 AM, lars hofhansl <[EMAIL PROTECTED]>
>> wrote:
>> >>>
>> >>> > This is an open source project, as long as there is a volunteer to
>> >>> > backport a patch I see no problem with doing this.
>> >>> > The only thing we as the community should ensure is that it must be
>> >>> > demonstrated that the patch does not destabilize the 0.94 code base;

That is only if we do not backport stabilizing "features". There is an "opportunity cost" to be paid if we take a too rigorous approach too.

Take for example table-lock (which prompted this discussion). With that in place we can do safe online schema upgrade (that won't fail and leave the table in an undefined state when a concurrent split happens), it also allows for online merge.

Now, is that a destabilizing "feature", or will it make HBase more stable and hence an "improvement"? Depends on viewpoint, doesn't it?

-- Lars

________________________________
 From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, March 1, 2013 7:12 PM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 
@Lars: No, not any concern about anything already backported. Just a
preference to #2 because it seems to make things more stable and
easier to manage. New feature = new release. Given new sub-releases
are for fixes and improvements, but not new features. Also, if we
backport a feature in one or many previous releases, we will have to
backport also all the fixes each time there will be an issue. So we
will have more maintenant work on previous releases.

2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> I think the current way of risk vs rewards analysis is working well. We
> will just continue doing that on a case by case basis, discussing the
> implications on individual issues.
>
>
>
> On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]> wrote:
>
>> BTW are you concerned about any specific back port we did in the past? So
>> far we have not seen any destabilization in any of the 0.94 releases.
>>
>> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
>>
>> >Hi Lars, #2, does it mean you will stop back-porting the new features
>> >when it will become a "long-term" release? If so, I'm for option #2...
>> >
>> >JM
>> >
>> >In your option
>> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>> >> Thanks Lars, I think it is a good listing of the options we have.
>> >>
>> >> I'll be +1 for #1 and #2, with #1 being a preference.
>> >>
>> >> Enis
>> >>
>> >>
>> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2)
>> we
>> >>> have three options:
>> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
>> >>> destabilize 0.94.
>> >>> 2. Declare a certain point release (0.94.6 looks like a good
>> candidate) as
>> >>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> >>> 3. Categorically do not backport new features into 0.94 and defer to
>> 0.95.
>> >>>
>> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
>> >>>
>> >>> -- Lars
>> >>>
>> >>>
>> >>>
>> >>> ________________________________
>> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> >>> Sent: Friday, March 1, 2013 3:11 PM
>> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>> >>>
>> >>> I think we are basically agreeing -- my primary concern is bringing new
>> >>> features in vital paths introduces more risk, I'd rather not backport
>> major
>> >>> new features unless we achieve a higher level of assurance through
>> system
>> >>> and basic fault injection testing.
>> >>>
>> >>> For the three current examples -- snapshots, zk table locks, online
>> merge
>> >>> -- I actually would prefer not including any in apache 0.94.  Of the
>> bunch,
>> >>> I feel the table locks are the most risky since it affects vital paths
>> a
>> >>> user must use,  where as snapshots and online merge are features that a
>> >>> user could choose to use but does not necessarily have to use.  I'll
>> voice
>> >>> my concerns, reason for concerns, and justifications on the individual
>> >>> jiras.
>

That is only if we do not backport stabilizing "features". There is an
"opportunity cost" to be paid if we take a too rigorous approach too.

Take
 for example table-locks (which prompted this discussion). With that in
place we can do safe online schema changes (that won't fail and leave
the table in an undefined state when a concurrent split happens), it
also allows for online merge.

Now, is that a destabilizing
"feature", or will it make HBase more stable and hence is an "improvement"? Depends on viewpoint, doesn't it?
-- Lars
________________________________
 From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, March 1, 2013 7:12 PM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 
@Lars: No, not any concern about anything already backported. Just a
preference to #2 because it seems to make things more stable and
easier to manage. New feature = new release. Given new sub-releases
are for fixes and improvements, but not new features. Also, if we
backport a feature in one or many previous releases, we will have to
backport also all the fixes each time there will be an issue. So we
will have more maintenant work on previous releases.

2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> I think the current way of risk vs rewards analysis is working well. We
> will just continue doing that on a case by case basis, discussing the
> implications on individual issues.
>
>
>
> On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]> wrote:
>
>> BTW are you concerned about any specific back port we did in the past? So
>> far we have not seen any destabilization in any of the 0.94 releases.
>>
>> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
>>
>> >Hi Lars, #2, does it mean you will stop back-porting the new features
>> >when it will become a "long-term" release? If so, I'm for option #2...
>> >
>> >JM
>> >
>> >In your option
>> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>> >> Thanks Lars, I think it is a good listing of the options we have.
>> >>
>> >> I'll be +1 for #1 and #2, with #1 being a preference.
>> >>
>> >> Enis
>> >>
>> >>
>> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2)
>> we
>> >>> have three options:
>> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
>> >>> destabilize 0.94.
>> >>> 2. Declare a certain point release (0.94.6 looks like a good
>> candidate) as
>> >>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> >>> 3. Categorically do not backport new features into 0.94 and defer to
>> 0.95.
>> >>>
>> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
>> >>>
>> >>> -- Lars
>> >>>
>> >>>
>> >>>
>> >>> ________________________________
>> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
>> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> >>> Sent: Friday, March 1, 2013 3:11 PM
>> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>> >>>
>> >>> I think we are basically agreeing -- my primary concern is bringing new
>> >>> features in vital paths introduces more risk, I'd rather not backport
>> major
>> >>> new features unless we achieve a higher level of assurance through
>> system
>> >>> and basic fault injection testing.
>> >>>
>> >>> For the three current examples -- snapshots, zk table locks, online
>> merge
>> >>> -- I actually would prefer not including any in apache 0.94.  Of the
>> bunch,
>> >>> I feel the table locks are the most risky since it affects vital paths
>> a
>> >>> user must use,  where as snapshots and online merge are features that a
>> >>> user could choose to use but does not necessarily have to use.  I'll
>> voice
>> >>> my concerns, reason for concerns, and justifications on the individual
>> >>> jiras.

bq. That is only if we do not backport stabilizing "features".
Did you mean destabilizing above :-)

My preference is option #1. With option #2, the community would be dealing
with one more branch which would increase the amount of work validating
each release candidate.

To me, the difference between option #2 and the upcoming release candidates
of 0.95 would blur.

Cheers

On Fri, Mar 1, 2013 at 7:24 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> That is only if we do not backport stabilizing "features". There is an
> "opportunity cost" to be paid if we take a too rigorous approach too.
>
> Take
>  for example table-locks (which prompted this discussion). With that in
> place we can do safe online schema changes (that won't fail and leave
> the table in an undefined state when a concurrent split happens), it
> also allows for online merge.
>
> Now, is that a destabilizing
> "feature", or will it make HBase more stable and hence is an
> "improvement"? Depends on viewpoint, doesn't it?
> -- Lars
>
>
> ________________________________
>  From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, March 1, 2013 7:12 PM
> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>
> @Lars: No, not any concern about anything already backported. Just a
> preference to #2 because it seems to make things more stable and
> easier to manage. New feature = new release. Given new sub-releases
> are for fixes and improvements, but not new features. Also, if we
> backport a feature in one or many previous releases, we will have to
> backport also all the fixes each time there will be an issue. So we
> will have more maintenant work on previous releases.
>
> 2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> > I think the current way of risk vs rewards analysis is working well. We
> > will just continue doing that on a case by case basis, discussing the
> > implications on individual issues.
> >
> >
> >
> > On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]>
> wrote:
> >
> >> BTW are you concerned about any specific back port we did in the past?
> So
> >> far we have not seen any destabilization in any of the 0.94 releases.
> >>
> >> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
> >>
> >> >Hi Lars, #2, does it mean you will stop back-porting the new features
> >> >when it will become a "long-term" release? If so, I'm for option #2...
> >> >
> >> >JM
> >> >
> >> >In your option
> >> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> >> >> Thanks Lars, I think it is a good listing of the options we have.
> >> >>
> >> >> I'll be +1 for #1 and #2, with #1 being a preference.
> >> >>
> >> >> Enis
> >> >>
> >> >>
> >> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]>
> wrote:
> >> >>
> >> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or
> 0.96.2)
> >> we
> >> >>> have three options:
> >> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
> >> >>> destabilize 0.94.
> >> >>> 2. Declare a certain point release (0.94.6 looks like a good
> >> candidate) as
> >> >>> a "long term", create an 0.94.6 branch (in addition to the usual
> 0.94.6
> >> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer
> to
> >> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
> >> >>> 3. Categorically do not backport new features into 0.94 and defer to
> >> 0.95.
> >> >>>
> >> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
> >> >>>
> >> >>> -- Lars
> >> >>>
> >> >>>
> >> >>>
> >> >>> ________________________________
> >> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> >> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
> >> >>> Sent: Friday, March 1, 2013 3:11 PM
> >> >>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
> >> >>>
> >> >>> I think we are basically agreeing -- my primary concern is bringing
> new
> >> >>> features in vital paths introduces more risk, I'd rather not
> backport
> >> major
> >> >>

I did mean "stablizing". What I was trying to point is that stuff we backport might stabilize HBase.

________________________________
 From: Ted Yu <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
Sent: Friday, March 1, 2013 7:30 PM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 
bq. That is only if we do not backport stabilizing "features".
Did you mean destabilizing above :-)

My preference is option #1. With option #2, the community would be dealing
with one more branch which would increase the amount of work validating
each release candidate.

To me, the difference between option #2 and the upcoming release candidates
of 0.95 would blur.

Cheers

On Fri, Mar 1, 2013 at 7:24 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> That is only if we do not backport stabilizing "features". There is an
> "opportunity cost" to be paid if we take a too rigorous approach too.
>
> Take
>  for example table-locks (which prompted this discussion). With that in
> place we can do safe online schema changes (that won't fail and leave
> the table in an undefined state when a concurrent split happens), it
> also allows for online merge.
>
> Now, is that a destabilizing
> "feature", or will it make HBase more stable and hence is an
> "improvement"? Depends on viewpoint, doesn't it?
> -- Lars
>
>
> ________________________________
>  From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, March 1, 2013 7:12 PM
> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>
> @Lars: No, not any concern about anything already backported. Just a
> preference to #2 because it seems to make things more stable and
> easier to manage. New feature = new release. Given new sub-releases
> are for fixes and improvements, but not new features. Also, if we
> backport a feature in one or many previous releases, we will have to
> backport also all the fixes each time there will be an issue. So we
> will have more maintenant work on previous releases.
>
> 2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> > I think the current way of risk vs rewards analysis is working well. We
> > will just continue doing that on a case by case basis, discussing the
> > implications on individual issues.
> >
> >
> >
> > On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]>
> wrote:
> >
> >> BTW are you concerned about any specific back port we did in the past?
> So
> >> far we have not seen any destabilization in any of the 0.94 releases.
> >>
> >> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
> >>
> >> >Hi Lars, #2, does it mean you will stop back-porting the new features
> >> >when it will become a "long-term" release? If so, I'm for option #2...
> >> >
> >> >JM
> >> >
> >> >In your option
> >> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> >> >> Thanks Lars, I think it is a good listing of the options we have.
> >> >>
> >> >> I'll be +1 for #1 and #2, with #1 being a preference.
> >> >>
> >> >> Enis
> >> >>
> >> >>
> >> >> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]>
> wrote:
> >> >>
> >> >>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or
> 0.96.2)
> >> we
> >> >>> have three options:
> >> >>> 1. Backport new features to 0.94 as we see fit as long as we do not
> >> >>> destabilize 0.94.
> >> >>> 2. Declare a certain point release (0.94.6 looks like a good
> >> candidate) as
> >> >>> a "long term", create an 0.94.6 branch (in addition to the usual
> 0.94.6
> >> >>> tag) and than create 0.94.6.x fix only releases. I would volunteer
> to
> >> >>> maintain a 0.94.6 branch in addition to the 0.94 branch.
> >> >>> 3. Categorically do not backport new features into 0.94 and defer to
> >> 0.95.
> >> >>>
> >> >>> I'd be +1 on option #1 and #2, and -1 on option #3.
> >> >>>
> >> >>> -- Lars
> >> >>>
> >> >>>
> >> >>>
> >> >>> ________________________________
> >> >>>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> >> >>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>

New feature is a red herring imho: To me the only question is the
regression risk.. And a feature can have a much lower regression risk than
a bug fix. I guess we've all seen a fix for a non critical bug putting down
a production system. Being able to backport features is a competitive
advantage that leverages on a good architecture and a good test suite.
Maintaining a branch adds a cost for everybody: if you have a bug to fix in
94.6.1, you need to fix it in 0.94.7 as well. So we should do it only if we
really have to, and plan it accordingly (i.e. we should not have to create
a 0.94.7.1 a week after the creation of the 0.94.6.1).

In the future, the test suite should also help us to estimate and minimize
the risk. We're not there yet, but having a good test coverage is key for
version 1 imho.

So that makes me +1 for backport, and  0 for branching (+1 if there is a
good reason and a plan, but here it's a theoretical discussion, so,... ;-) )

Nicolas
On Sat, Mar 2, 2013 at 4:44 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> I did mean "stablizing". What I was trying to point is that stuff we
> backport might stabilize HBase.
>
>
>
> ________________________________
>  From: Ted Yu <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
> Sent: Friday, March 1, 2013 7:30 PM
> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>
> bq. That is only if we do not backport stabilizing "features".
> Did you mean destabilizing above :-)
>
> My preference is option #1. With option #2, the community would be dealing
> with one more branch which would increase the amount of work validating
> each release candidate.
>
> To me, the difference between option #2 and the upcoming release candidates
> of 0.95 would blur.
>
> Cheers
>
> On Fri, Mar 1, 2013 at 7:24 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > That is only if we do not backport stabilizing "features". There is an
> > "opportunity cost" to be paid if we take a too rigorous approach too.
> >
> > Take
> >  for example table-locks (which prompted this discussion). With that in
> > place we can do safe online schema changes (that won't fail and leave
> > the table in an undefined state when a concurrent split happens), it
> > also allows for online merge.
> >
> > Now, is that a destabilizing
> > "feature", or will it make HBase more stable and hence is an
> > "improvement"? Depends on viewpoint, doesn't it?
> > -- Lars
> >
> >
> > ________________________________
> >  From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Sent: Friday, March 1, 2013 7:12 PM
> > Subject: Re: [DISCUSS] More new feature backports to 0.94.
> >
> > @Lars: No, not any concern about anything already backported. Just a
> > preference to #2 because it seems to make things more stable and
> > easier to manage. New feature = new release. Given new sub-releases
> > are for fixes and improvements, but not new features. Also, if we
> > backport a feature in one or many previous releases, we will have to
> > backport also all the fixes each time there will be an issue. So we
> > will have more maintenant work on previous releases.
> >
> > 2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
> > > I think the current way of risk vs rewards analysis is working well. We
> > > will just continue doing that on a case by case basis, discussing the
> > > implications on individual issues.
> > >
> > >
> > >
> > > On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]>
> > wrote:
> > >
> > >> BTW are you concerned about any specific back port we did in the past?
> > So
> > >> far we have not seen any destabilization in any of the 0.94 releases.
> > >>
> > >> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
> > >>
> > >> >Hi Lars, #2, does it mean you will stop back-porting the new features
> > >> >when it will become a "long-term" release? If so, I'm for option
> #2...
> > >> >
> > >> >JM
> > >> >
> > >> >In your option
> > >> >2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:

I agree with Nicolas' assessment.

Cheers

On Mar 2, 2013, at 3:43 AM, Nicolas Liochon <[EMAIL PROTECTED]> wrote:

> New feature is a red herring imho: To me the only question is the
> regression risk.. And a feature can have a much lower regression risk than
> a bug fix. I guess we've all seen a fix for a non critical bug putting down
> a production system. Being able to backport features is a competitive
> advantage that leverages on a good architecture and a good test suite.
> Maintaining a branch adds a cost for everybody: if you have a bug to fix in
> 94.6.1, you need to fix it in 0.94.7 as well. So we should do it only if we
> really have to, and plan it accordingly (i.e. we should not have to create
> a 0.94.7.1 a week after the creation of the 0.94.6.1).
>
> In the future, the test suite should also help us to estimate and minimize
> the risk. We're not there yet, but having a good test coverage is key for
> version 1 imho.
>
> So that makes me +1 for backport, and  0 for branching (+1 if there is a
> good reason and a plan, but here it's a theoretical discussion, so,... ;-) )
>
> Nicolas
>
>
> On Sat, Mar 2, 2013 at 4:44 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
>> I did mean "stablizing". What I was trying to point is that stuff we
>> backport might stabilize HBase.
>>
>>
>>
>> ________________________________
>> From: Ted Yu <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> Sent: Friday, March 1, 2013 7:30 PM
>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>>
>> bq. That is only if we do not backport stabilizing "features".
>> Did you mean destabilizing above :-)
>>
>> My preference is option #1. With option #2, the community would be dealing
>> with one more branch which would increase the amount of work validating
>> each release candidate.
>>
>> To me, the difference between option #2 and the upcoming release candidates
>> of 0.95 would blur.
>>
>> Cheers
>>
>> On Fri, Mar 1, 2013 at 7:24 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>
>>> That is only if we do not backport stabilizing "features". There is an
>>> "opportunity cost" to be paid if we take a too rigorous approach too.
>>>
>>> Take
>>> for example table-locks (which prompted this discussion). With that in
>>> place we can do safe online schema changes (that won't fail and leave
>>> the table in an undefined state when a concurrent split happens), it
>>> also allows for online merge.
>>>
>>> Now, is that a destabilizing
>>> "feature", or will it make HBase more stable and hence is an
>>> "improvement"? Depends on viewpoint, doesn't it?
>>> -- Lars
>>>
>>>
>>> ________________________________
>>> From: Jean-Marc Spaggiari <[EMAIL PROTECTED]>
>>> To: [EMAIL PROTECTED]
>>> Sent: Friday, March 1, 2013 7:12 PM
>>> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>>>
>>> @Lars: No, not any concern about anything already backported. Just a
>>> preference to #2 because it seems to make things more stable and
>>> easier to manage. New feature = new release. Given new sub-releases
>>> are for fixes and improvements, but not new features. Also, if we
>>> backport a feature in one or many previous releases, we will have to
>>> backport also all the fixes each time there will be an issue. So we
>>> will have more maintenant work on previous releases.
>>>
>>> 2013/3/1 Enis Söztutar <[EMAIL PROTECTED]>:
>>>> I think the current way of risk vs rewards analysis is working well. We
>>>> will just continue doing that on a case by case basis, discussing the
>>>> implications on individual issues.
>>>>
>>>>
>>>>
>>>> On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[EMAIL PROTECTED]>
>>> wrote:
>>>>
>>>>> BTW are you concerned about any specific back port we did in the past?
>>> So
>>>>> far we have not seen any destabilization in any of the 0.94 releases.
>>>>>
>>>>> Jean-Marc Spaggiari <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> Hi Lars, #2, does it mean you will stop back-porting the new features

In general, I have a preference against backporting  features for the
reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear,
this preference doesn't mean I am -1 to all backports onto the stable
apache branch.  Let's do it case-by-case; my main ask is to make major
backports rare and to make it the norm to require significantly more
evidence of testing than usual.  I will -1 a major backport that lacks this
evidence.  This will come up again in the future.

With the cases Lars proposed -- I prefer #3 (just say no) but find #1 (be
very careful) acceptable given higher level of evidence.  #2 (new release
branch) is onerous -- I'd rather we just get preview-release branches out
more frequently to not have deal with this.  Arguably, the reason we have
the preview-release branches serve the purpose of getting releases out more
frequently and giving a feature time to harden from a few common points.
 My hope is that these preview release will replace what were the 0.x.0 and
0.x.1 releases from  previous versions

So what kind of evidence would I like to see? We can use snapshots case as
an example.

When backporting snapshots was brought up, I actually preferred that we not
backport that feature.  There was demand, so we agreed that we'd do it but
no backport it until it is "rock solid".  Here's evidence to support the
case that the feature and backport is solid:
* It's code history is publicly documented and has been available since
December.
* It's design documentation has been available for even longer.
* The feature is mostly additive and doesn't affect vital paths.
* It was tested against trunk and the later tested against a 0.94 variant
that is closer to the target apache branch.
* The version in the trunk branch has been reviewed by 5 committers.
* Limitations are either documented (please let me know if we should
improve it more) or non-critical.
* Testing and hardening anecdotes have been documented in the original and
backport jira.  There has been some relatively long term testing and fault
injection testing (roughly 4-6 weeks).
* It will be backported in a "big bang" -- all pieces get added or none
will.

This is a level I consider to be stronger than the normal testing expected
for a patch.  Ideally, something at least this level is what I would expect
for other major backports.  Do we agree on that?

For the table locks case, there maybe some of this may be a misperception
in timing from my point of view.  I see a notification about this in jira
which makes me think it is more imminent.   Looking into it, I see that
currently the development and application of the zk table lock feature
isn't complete -- the mechanism is committed but it isn't applied and
integrated into all the operations (split, assign etc still on the way).
 I've asked for documentation and Enis has graciously added a great design
doc that will help reviewers understand it.  I'd love to be able to spend
time system testing to really beating it up or at least have anecdotes from
folks about their efforts on the apache verison.  Finally, I would want to
see this feature come in as a big bang -- get it complete enough in trunk
before backporting the pieces to a stable branch.

I haven't invested time into the online merge backport decision but my
instinct there is to not port the feature as well.  It is less risky since
it is an additive feature but has less reward since we already have a
less-friendly-but-comparable mechanism.  Since merge seems similar to split
(which took a while to get right) testing its correctness in failure cases
at the system level would be a prereq.

Jon.

On Sat, Mar 2, 2013 at 3:43 AM, Nicolas Liochon <[EMAIL PROTECTED]> wrote:

> New feature is a red herring imho: To me the only question is the
> regression risk.. And a feature can have a much lower regression risk than
> a bug fix. I guess we've all seen a fix for a non critical bug putting down
> a production system. Being able to backport features is a competitive

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

bq. I would want to see this feature come in as a big bang -- get it
complete enough in trunk before backporting the pieces to a stable branch.

I agree with Jon on this point.
Porting in one big patch allows us to think through related use cases.
Another benefit is that there wouldn't be glitch in API, in case the first
batch of backports went into 0.94.x and the second batch goes into 0.94.x+1
Running the feature through test suite in trunk continuously gives us time
to discover defects before the backport.

Cheers

On Sat, Mar 2, 2013 at 7:36 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> In general, I have a preference against backporting  features for the
> reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear,
> this preference doesn't mean I am -1 to all backports onto the stable
> apache branch.  Let's do it case-by-case; my main ask is to make major
> backports rare and to make it the norm to require significantly more
> evidence of testing than usual.  I will -1 a major backport that lacks this
> evidence.  This will come up again in the future.
>
> With the cases Lars proposed -- I prefer #3 (just say no) but find #1 (be
> very careful) acceptable given higher level of evidence.  #2 (new release
> branch) is onerous -- I'd rather we just get preview-release branches out
> more frequently to not have deal with this.  Arguably, the reason we have
> the preview-release branches serve the purpose of getting releases out more
> frequently and giving a feature time to harden from a few common points.
>  My hope is that these preview release will replace what were the 0.x.0 and
> 0.x.1 releases from  previous versions
>
> So what kind of evidence would I like to see? We can use snapshots case as
> an example.
>
> When backporting snapshots was brought up, I actually preferred that we not
> backport that feature.  There was demand, so we agreed that we'd do it but
> no backport it until it is "rock solid".  Here's evidence to support the
> case that the feature and backport is solid:
> * It's code history is publicly documented and has been available since
> December.
> * It's design documentation has been available for even longer.
> * The feature is mostly additive and doesn't affect vital paths.
> * It was tested against trunk and the later tested against a 0.94 variant
> that is closer to the target apache branch.
> * The version in the trunk branch has been reviewed by 5 committers.
> * Limitations are either documented (please let me know if we should
> improve it more) or non-critical.
> * Testing and hardening anecdotes have been documented in the original and
> backport jira.  There has been some relatively long term testing and fault
> injection testing (roughly 4-6 weeks).
> * It will be backported in a "big bang" -- all pieces get added or none
> will.
>
> This is a level I consider to be stronger than the normal testing expected
> for a patch.  Ideally, something at least this level is what I would expect
> for other major backports.  Do we agree on that?
>
> For the table locks case, there maybe some of this may be a misperception
> in timing from my point of view.  I see a notification about this in jira
> which makes me think it is more imminent.   Looking into it, I see that
> currently the development and application of the zk table lock feature
> isn't complete -- the mechanism is committed but it isn't applied and
> integrated into all the operations (split, assign etc still on the way).
>  I've asked for documentation and Enis has graciously added a great design
> doc that will help reviewers understand it.  I'd love to be able to spend
> time system testing to really beating it up or at least have anecdotes from
> folks about their efforts on the apache verison.  Finally, I would want to
> see this feature come in as a big bang -- get it complete enough in trunk
> before backporting the pieces to a stable branch.
>
> I haven't invested time into the online merge backport decision but my

To be clear, a key point is that unit testing is a required but not
sufficient.  I need anecdotes about system testing with at least some
unexpected fault handling and stress.  If the feature is actively being
developed still, go into a dev branch (git hub or svn) that eventually
merges.  Some info about perf would be nice as well if that is affected.

In cases that aren't too burdensome, I would prefer consecutive individual
commits to a stable branch as opposed to a single mega patch.  This of
course is a case-by-case decision. (snapshots is about 80 patches.. way too
burdensome).

Jon.

On Sat, Mar 2, 2013 at 8:14 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

> bq. I would want to see this feature come in as a big bang -- get it
> complete enough in trunk before backporting the pieces to a stable branch.
>
> I agree with Jon on this point.
> Porting in one big patch allows us to think through related use cases.
> Another benefit is that there wouldn't be glitch in API, in case the first
> batch of backports went into 0.94.x and the second batch goes into 0.94.x+1
> Running the feature through test suite in trunk continuously gives us time
> to discover defects before the backport.
>
> Cheers
>
> On Sat, Mar 2, 2013 at 7:36 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
>
> > In general, I have a preference against backporting  features for the
> > reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear,
> > this preference doesn't mean I am -1 to all backports onto the stable
> > apache branch.  Let's do it case-by-case; my main ask is to make major
> > backports rare and to make it the norm to require significantly more
> > evidence of testing than usual.  I will -1 a major backport that lacks
> this
> > evidence.  This will come up again in the future.
> >
> > With the cases Lars proposed -- I prefer #3 (just say no) but find #1 (be
> > very careful) acceptable given higher level of evidence.  #2 (new release
> > branch) is onerous -- I'd rather we just get preview-release branches out
> > more frequently to not have deal with this.  Arguably, the reason we have
> > the preview-release branches serve the purpose of getting releases out
> more
> > frequently and giving a feature time to harden from a few common points.
> >  My hope is that these preview release will replace what were the 0.x.0
> and
> > 0.x.1 releases from  previous versions
> >
> > So what kind of evidence would I like to see? We can use snapshots case
> as
> > an example.
> >
> > When backporting snapshots was brought up, I actually preferred that we
> not
> > backport that feature.  There was demand, so we agreed that we'd do it
> but
> > no backport it until it is "rock solid".  Here's evidence to support the
> > case that the feature and backport is solid:
> > * It's code history is publicly documented and has been available since
> > December.
> > * It's design documentation has been available for even longer.
> > * The feature is mostly additive and doesn't affect vital paths.
> > * It was tested against trunk and the later tested against a 0.94 variant
> > that is closer to the target apache branch.
> > * The version in the trunk branch has been reviewed by 5 committers.
> > * Limitations are either documented (please let me know if we should
> > improve it more) or non-critical.
> > * Testing and hardening anecdotes have been documented in the original
> and
> > backport jira.  There has been some relatively long term testing and
> fault
> > injection testing (roughly 4-6 weeks).
> > * It will be backported in a "big bang" -- all pieces get added or none
> > will.
> >
> > This is a level I consider to be stronger than the normal testing
> expected
> > for a patch.  Ideally, something at least this level is what I would
> expect
> > for other major backports.  Do we agree on that?
> >
> > For the table locks case, there maybe some of this may be a misperception
> > in timing from my point of view.  I see a notification about this in jira
>
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

I on the same page as N here.

There are "features" that make HBase more stable. Table locks (when implemented correctly and finished of course) could be such a feature.
I do not understand how 0.95 plays into this. There is no rolling upgrade path from 0.94 to 0.95 and 0.95 is not a stable release.

-- Lars

________________________________
 From: Jonathan Hsieh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: lars hofhansl <[EMAIL PROTECTED]>
Sent: Saturday, March 2, 2013 7:36 AM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 

In general, I have a preference against backporting  features for the reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear, this preference doesn't mean I am -1 to all backports onto the stable apache branch.  Let's do it case-by-case; my main ask is to make major backports rare and to make it the norm to require significantly more evidence of testing than usual.  I will -1 a major backport that lacks this evidence.  This will come up again in the future.

With the cases Lars proposed -- I prefer #3 (just say no) but find #1 (be very careful) acceptable given higher level of evidence.  #2 (new release branch) is onerous -- I'd rather we just get preview-release branches out more frequently to not have deal with this.  Arguably, the reason we have the preview-release branches serve the purpose of getting releases out more frequently and giving a feature time to harden from a few common points.  My hope is that these preview release will replace what were the 0.x.0 and 0.x.1 releases from  previous versions 

So what kind of evidence would I like to see? We can use snapshots case as an example.
When backporting snapshots was brought up, I actually preferred that we not backport that feature.  There was demand, so we agreed that we'd do it but no backport it until it is "rock solid".  Here's evidence to support the case that the feature and backport is solid:

* It's code history is publicly documented and has been available since December.
* It's design documentation has been available for even longer.  
* The feature is mostly additive and doesn't affect vital paths.
* It was tested against trunk and the later tested against a 0.94 variant that is closer to the target apache branch.  
* The version in the trunk branch has been reviewed by 5 committers.
* Limitations are either documented (please let me know if we should improve it more) or non-critical.
* Testing and hardening anecdotes have been documented in the original and backport jira.  There has been some relatively long term testing and fault injection testing (roughly 4-6 weeks).
* It will be backported in a "big bang" -- all pieces get added or none will.
 
This is a level I consider to be stronger than the normal testing expected for a patch.  Ideally, something at least this level is what I would expect for other major backports.  Do we agree on that?

For the table locks case, there maybe some of this may be a misperception in timing from my point of view.  I see a notification about this in jira which makes me think it is more imminent.   Looking into it, I see that currently the development and application of the zk table lock feature isn't complete -- the mechanism is committed but it isn't applied and integrated into all the operations (split, assign etc still on the way).  I've asked for documentation and Enis has graciously added a great design doc that will help reviewers understand it.  I'd love to be able to spend time system testing to really beating it up or at least have anecdotes from folks about their efforts on the apache verison.  Finally, I would want to see this feature come in as a big bang -- get it complete enough in trunk before backporting the pieces to a stable branch.

I haven't invested time into the online merge backport decision but my instinct there is to not port the feature as well.  It is less risky since it is an additive feature but has less reward since we already have a less-friendly-but-comparable mechanism.  Since merge seems similar to split (which took a while to get right) testing its correctness in failure cases at the system level would be a prereq.

Jon.
On Sat, Mar 2, 2013 at 3:43 AM, Nicolas Liochon <[EMAIL PROTECTED]> wrote:

New feature is a red herring imho: To me the only question is the
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera

// [EMAIL PROTECTED]

In the end, I think, boils down to the established process.
Anybody can open a jira and propose a patch. If it gets +1's from a few committers and no -1's we should commit it.
As I said on HBASE-7965, if we cannot convince Jon and Elliot that this is safe to do, we should not do it (either because Enis and I agree, or because Jon -1's it). No hard feeling either way, I hope (none from my side at least).
It seems we're mostly in agreement and just differ a bit in what constitutes a feature vs. a bug fix.

-- Lars

________________________________
 From: Jonathan Hsieh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: lars hofhansl <[EMAIL PROTECTED]>
Sent: Saturday, March 2, 2013 8:26 AM
Subject: Re: [DISCUSS] More new feature backports to 0.94.
 

To be clear, a key point is that unit testing is a required but not sufficient.  I need anecdotes about system testing with at least some unexpected fault handling and stress.  If the feature is actively being developed still, go into a dev branch (git hub or svn) that eventually merges.  Some info about perf would be nice as well if that is affected.

In cases that aren't too burdensome, I would prefer consecutive individual commits to a stable branch as opposed to a single mega patch.  This of course is a case-by-case decision. (snapshots is about 80 patches.. way too burdensome).
Jon.
On Sat, Mar 2, 2013 at 8:14 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

bq. I would want to see this feature come in as a big bang -- get it
>
>complete enough in trunk before backporting the pieces to a stable branch.
>
>I agree with Jon on this point.
>Porting in one big patch allows us to think through related use cases.
>Another benefit is that there wouldn't be glitch in API, in case the first
>batch of backports went into 0.94.x and the second batch goes into 0.94.x+1
>Running the feature through test suite in trunk continuously gives us time
>to discover defects before the backport.
>
>Cheers
>
>
>On Sat, Mar 2, 2013 at 7:36 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
>
>> In general, I have a preference against backporting  features for the
>> reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear,
>> this preference doesn't mean I am -1 to all backports onto the stable
>> apache branch.  Let's do it case-by-case; my main ask is to make major
>> backports rare and to make it the norm to require significantly more
>> evidence of testing than usual.  I will -1 a major backport that lacks this
>> evidence.  This will come up again in the future.
>>
>> With the cases Lars proposed -- I prefer #3 (just say no) but find #1 (be
>> very careful) acceptable given higher level of evidence.  #2 (new release
>> branch) is onerous -- I'd rather we just get preview-release branches out
>> more frequently to not have deal with this.  Arguably, the reason we have
>> the preview-release branches serve the purpose of getting releases out more
>> frequently and giving a feature time to harden from a few common points.
>>  My hope is that these preview release will replace what were the 0.x.0 and
>> 0.x.1 releases from  previous versions
>>
>> So what kind of evidence would I like to see? We can use snapshots case as
>> an example.
>>
>> When backporting snapshots was brought up, I actually preferred that we not
>> backport that feature.  There was demand, so we agreed that we'd do it but
>> no backport it until it is "rock solid".  Here's evidence to support the
>> case that the feature and backport is solid:
>> * It's code history is publicly documented and has been available since
>> December.
>> * It's design documentation has been available for even longer.
>> * The feature is mostly additive and doesn't affect vital paths.
>> * It was tested against trunk and the later tested against a 0.94 variant
>> that is closer to the target apache branch.
>> * The version in the trunk branch has been reviewed by 5 committers.
>> * Limitations are either documented (please let me know if we should
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera

// [EMAIL PROTECTED]

I don't think it is a debate about feature vs bug fix -- I've been trying
to make a general case about major feature backports.   I agree that we are
basically on the same page for the general case.    I've been using some of
the current candidate features as examples but I'm really trying to focus
on defining a general "finished" condition early-on for big backports
(bullet points that would be highlights of the next release), and to
express the need for higher scrutiny on these commits.  I'll post specific
details for each proposal in the appropriate jira.

In the specific case, I actually do want the table locks, but only after
they are done and have some evidence of stability.   I would much rather
have known bugs with known workarounds instead of unknown issues introduced
by a backported feature, and would like to avoid hackery introduced by
compatibility bugs fire drills.

The points I'm trying to make about 0.95.x is that ideally it is where the
new features get further hardened (as opposed to the stable branch).
 Ideally the release manager for that version will start gate keeping what
new major features/changes make it in there so that we have a chance of
releasing it and a 0.96 sometime soon. :)

Jon.

On Sat, Mar 2, 2013 at 12:46 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> In the end, I think, boils down to the established process.
> Anybody can open a jira and propose a patch. If it gets +1's from a few
> committers and no -1's we should commit it.
> As I said on HBASE-7965, if we cannot convince Jon and Elliot that this is
> safe to do, we should not do it (either because Enis and I agree, or
> because Jon -1's it). No hard feeling either way, I hope (none from my side
> at least).
>
>
> It seems we're mostly in agreement and just differ a bit in what
> constitutes a feature vs. a bug fix.
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: lars hofhansl <[EMAIL PROTECTED]>
> Sent: Saturday, March 2, 2013 8:26 AM
> Subject: Re: [DISCUSS] More new feature backports to 0.94.
>
>
> To be clear, a key point is that unit testing is a required but not
> sufficient.  I need anecdotes about system testing with at least some
> unexpected fault handling and stress.  If the feature is actively being
> developed still, go into a dev branch (git hub or svn) that eventually
> merges.  Some info about perf would be nice as well if that is affected.
>
> In cases that aren't too burdensome, I would prefer consecutive individual
> commits to a stable branch as opposed to a single mega patch.  This of
> course is a case-by-case decision. (snapshots is about 80 patches.. way too
> burdensome).
>
>
> Jon.
>
>
> On Sat, Mar 2, 2013 at 8:14 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> bq. I would want to see this feature come in as a big bang -- get it
> >
> >complete enough in trunk before backporting the pieces to a stable branch.
> >
> >I agree with Jon on this point.
> >Porting in one big patch allows us to think through related use cases.
> >Another benefit is that there wouldn't be glitch in API, in case the first
> >batch of backports went into 0.94.x and the second batch goes into
> 0.94.x+1
> >Running the feature through test suite in trunk continuously gives us time
> >to discover defects before the backport.
> >
> >Cheers
> >
> >
> >On Sat, Mar 2, 2013 at 7:36 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
> >
> >> In general, I have a preference against backporting  features for the
> >> reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear,
> >> this preference doesn't mean I am -1 to all backports onto the stable
> >> apache branch.  Let's do it case-by-case; my main ask is to make major
> >> backports rare and to make it the norm to require significantly more
> >> evidence of testing than usual.  I will -1 a major backport that lacks
> this
> >> evidence.  This will come up again in the future.
> >>
> >> With the cases Lars proposed -- I prefer #3 (just say no) but find #1

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

On Sat, Mar 2, 2013 at 1:49 PM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> The points I'm trying to make about 0.95.x is that ideally it is where the
> new features get further hardened (as opposed to the stable branch).
>  Ideally the release manager for that version will start gate keeping what
> new major features/changes make it in there so that we have a chance of
> releasing it and a 0.96 sometime soon. :)
>

I heard that!

Was going to write a note to the above effect about the gate closing with a
short list of things I'll entertain pulling in if 'done'.  Monday.

St.Ack

Concur. +1 on option #1 and #2, with #1 preferred, -1 on #3.

On Sat, Mar 2, 2013 at 10:10 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
> have three options:
> 1. Backport new features to 0.94 as we see fit as long as we do not
> destabilize 0.94.
> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> tag) and than create 0.94.6.x fix only releases. I would volunteer to
> maintain a 0.94.6 branch in addition to the 0.94 branch.
> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>
> I'd be +1 on option #1 and #2, and -1 on option #3.
>
> -- Lars
>

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Do we need to start another thread voting for options 1 and 2 ?

We should make a decision soon so that the next 0.94 release can be made.

Cheers

On Mar 3, 2013, at 5:50 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> Concur. +1 on option #1 and #2, with #1 preferred, -1 on #3.
>
> On Sat, Mar 2, 2013 at 10:10 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
>> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
>> have three options:
>> 1. Backport new features to 0.94 as we see fit as long as we do not
>> destabilize 0.94.
>> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
>> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>>
>> I'd be +1 on option #1 and #2, and -1 on option #3.
>>
>> -- Lars
>
> --
> Best regards,
>
>   - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

I'm not sure that is necessary. I think we can establish consensus without
doing so, but if you like, call a vote.
On Sun, Mar 3, 2013 at 10:12 PM, Ted <[EMAIL PROTECTED]> wrote:

> Do we need to start another thread voting for options 1 and 2 ?
>
> We should make a decision soon so that the next 0.94 release can be made.
>
> Cheers
>
> On Mar 3, 2013, at 5:50 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>
> > Concur. +1 on option #1 and #2, with #1 preferred, -1 on #3.
> >
> > On Sat, Mar 2, 2013 at 10:10 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> >
> >> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
> >> have three options:
> >> 1. Backport new features to 0.94 as we see fit as long as we do not
> >> destabilize 0.94.
> >> 2. Declare a certain point release (0.94.6 looks like a good candidate)
> as
> >> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> >> tag) and than create 0.94.6.x fix only releases. I would volunteer to
> >> maintain a 0.94.6 branch in addition to the 0.94 branch.
> >> 3. Categorically do not backport new features into 0.94 and defer to
> 0.95.
> >>
> >> I'd be +1 on option #1 and #2, and -1 on option #3.
> >>
> >> -- Lars
> >
> > --
> > Best regards,
> >
> >   - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

I agree with Andrew. I don't think a vote is required.

It seems that people who are more for option #2 also said there are
pretty ok with option #1 too, while people who are mainly for option
#1 said 0 or -1 for options #2 and #3...

So even if I prefer option #2, I think option #1 got more "votes".

JM

2013/3/3 Andrew Purtell <[EMAIL PROTECTED]>:
> I'm not sure that is necessary. I think we can establish consensus without
> doing so, but if you like, call a vote.
>
>
> On Sun, Mar 3, 2013 at 10:12 PM, Ted <[EMAIL PROTECTED]> wrote:
>
>> Do we need to start another thread voting for options 1 and 2 ?
>>
>> We should make a decision soon so that the next 0.94 release can be made.
>>
>> Cheers
>>
>> On Mar 3, 2013, at 5:50 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>>
>> > Concur. +1 on option #1 and #2, with #1 preferred, -1 on #3.
>> >
>> > On Sat, Mar 2, 2013 at 10:10 AM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> >
>> >> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
>> >> have three options:
>> >> 1. Backport new features to 0.94 as we see fit as long as we do not
>> >> destabilize 0.94.
>> >> 2. Declare a certain point release (0.94.6 looks like a good candidate)
>> as
>> >> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
>> >> tag) and than create 0.94.6.x fix only releases. I would volunteer to
>> >> maintain a 0.94.6 branch in addition to the 0.94 branch.
>> >> 3. Categorically do not backport new features into 0.94 and defer to
>> 0.95.
>> >>
>> >> I'd be +1 on option #1 and #2, and -1 on option #3.
>> >>
>> >> -- Lars
>> >
>> > --
>> > Best regards,
>> >
>> >   - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>>
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
> have three options:
> 1. Backport new features to 0.94 as we see fit as long as we do not
> destabilize 0.94.
> 2. Declare a certain point release (0.94.6 looks like a good candidate) as
> a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> tag) and than create 0.94.6.x fix only releases. I would volunteer to
> maintain a 0.94.6 branch in addition to the 0.94 branch.
> 3. Categorically do not backport new features into 0.94 and defer to 0.95.
>

I want us to get to #3.  Lets get to 1.0.0 sooner rather than later so we
have more numbers to play with (0.96 == 1.0.0?)

Regards #1, +1, but how to verify we do not destabilize 0.94?

-1 on #2.  Just confuses.

As has been said already, we'd probably not be having this conversation nor
feeling the need to backport features if 0.96 was out.

St.Ack

The general understanding is that we should not have been in this
condition. But since we are, and as per Lars' comments, we desperately need
some of the features.

Let's move the discussions to individual backporting jiras. We can gauge
reward / risk on a case by case basis (which we have been doing a decent
job so far)

Enis
On Mon, Mar 4, 2013 at 1:27 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we
> > have three options:
> > 1. Backport new features to 0.94 as we see fit as long as we do not
> > destabilize 0.94.
> > 2. Declare a certain point release (0.94.6 looks like a good candidate)
> as
> > a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> > tag) and than create 0.94.6.x fix only releases. I would volunteer to
> > maintain a 0.94.6 branch in addition to the 0.94 branch.
> > 3. Categorically do not backport new features into 0.94 and defer to
> 0.95.
> >
>
> I want us to get to #3.  Lets get to 1.0.0 sooner rather than later so we
> have more numbers to play with (0.96 == 1.0.0?)
>
> Regards #1, +1, but how to verify we do not destabilize 0.94?
>
> -1 on #2.  Just confuses.
>
> As has been said already, we'd probably not be having this conversation nor
> feeling the need to backport features if 0.96 was out.
>
> St.Ack
>

> Let's move the discussions to individual backporting jiras.

+1

On Tuesday, March 5, 2013, Enis Söztutar wrote:

> The general understanding is that we should not have been in this
> condition. But since we are, and as per Lars' comments, we desperately
> need some of the features.
>
> Let's move the discussions to individual backporting jiras. We can gauge reward
> / risk on a case by case basis (which we have been doing a decent
> job so far)
>
> Enis
>
>
> On Mon, Mar 4, 2013 at 1:27 PM, Stack <[EMAIL PROTECTED] <javascript:;>>
> wrote:
>
> > On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <[EMAIL PROTECTED]<javascript:;>>
> wrote:
> >
> > > So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2)
> we
> > > have three options:
> > > 1. Backport new features to 0.94 as we see fit as long as we do not
> > > destabilize 0.94.
> > > 2. Declare a certain point release (0.94.6 looks like a good candidate)
> > as
> > > a "long term", create an 0.94.6 branch (in addition to the usual 0.94.6
> > > tag) and than create 0.94.6.x fix only releases. I would volunteer to
> > > maintain a 0.94.6 branch in addition to the 0.94 branch.
> > > 3. Categorically do not backport new features into 0.94 and defer to
> > 0.95.
> > >
> >
> > I want us to get to #3.  Lets get to 1.0.0 sooner rather than later so we
> > have more numbers to play with (0.96 == 1.0.0?)
> >
> > Regards #1, +1, but how to verify we do not destabilize 0.94?
> >
> > -1 on #2.  Just confuses.
> >
> > As has been said already, we'd probably not be having this conversation
> nor
> > feeling the need to backport features if 0.96 was out.
> >
> > St.Ack
> >
>
--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)