Re: Backporting to active branches

[Andrew Purtell]

We don't have frequent enough releases with 0.98?


> On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh  wrote:
> 
> Users also deserve to get as few new surprises as possible.  Being on the
> supporting side of this, I've come to prefer preserving minor known issues
> to having new unknown issues caused of small improvements.
> 
> I prefer the conservative approach with "improvements", and prefer that
> maint/point release just backport critical fixes, security fixes, testing
> improvements (test only flakey fixups), recovery tooling (hbck updates),
> and critical perf regression fixes.
> 
> If not getting minors out fast enough is the main concern and motivator,
> I'd argue backporting more doesn't help the problem -- that is energy that
> could be spent helping get more minors out more frequently.   One of the
> things about having frequent point release like when we had with 0.94 was
> that we likely could have shipped some of the earlier 1.2.0rcs and fixed
> the criticals in next point release train.
> 
> Jon.
> 
>> On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk  wrote:
>> 
>> I appreciate Elliot's voice for conservatism on released branches. However
>> I don't think we're getting minor releases out the door fast enough,
>> especially when we have nice "improvements" that apply cleanly. Users
>> deserve to get as many of the improvements as are compatible for patch
>> releases, according to our guidelines.
>> 
>>> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark  wrote:
>>> 
>>> That one's on the edge for me. It's trying to work around a bug somewhere
>>> that has caused data loss in prod. So I would lean towards it being a bug
>>> fix.
>>> 
>>> However pulling from my last few filed jiras I would say these are all
>>> improvements:
>>> HBASE-15166
>>> HBASE-15146
>>> HBASE-15137
>>> HBASE-15083
>>> 
>>> Some of them fixed things that we hit in production but they didn't
>> change
>>> correctness or cause the system to be un-usable in the normal case. So I
>>> would classify them as improvements. For me I would want to backport only
>>> for patch releases fixes that fixed severe issues, things that changed
>>> correctness or caused a system to be un-usable.
>>> 
>>> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell 
>>> wrote:
>>> 
 Ok, in fairness there could be more debatable (or even not debatable)
 changes on branch-1 as you say. Also, a difference of perspective.
>> Would
 you for example consider HBASE-15211 a bug fix or improvement?
 
> On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark 
 wrote:
 
> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
 andrew.purt...@gmail.com>
> wrote:
> 
>> The majority of changes in branch-1 that I see are bug fixes.
> 
> 
> I think that's the point that you and I differ. For me I would
>> classify
> most things on branch-1 as improvements and there are very few bug
>>> fixes.
 
 
 
 --
 Best regards,
 
   - Andy
 
 Problems worthy of attack prove their worth by hitting back. - Piet
>> Hein
 (via Tom White)
> 
> 
> 
> -- 
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // j...@cloudera.com // @jmhsieh

Re: Backporting to active branches

[Nick Dimiduk]

I was speaking of the frequency of minor releases on the 1.x line, not 98.

On Friday, February 12, 2016, Andrew Purtell 
wrote:

> We don't have frequent enough releases with 0.98?
>
>
> > On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh  > wrote:
> >
> > Users also deserve to get as few new surprises as possible.  Being on the
> > supporting side of this, I've come to prefer preserving minor known
> issues
> > to having new unknown issues caused of small improvements.
> >
> > I prefer the conservative approach with "improvements", and prefer that
> > maint/point release just backport critical fixes, security fixes, testing
> > improvements (test only flakey fixups), recovery tooling (hbck updates),
> > and critical perf regression fixes.
> >
> > If not getting minors out fast enough is the main concern and motivator,
> > I'd argue backporting more doesn't help the problem -- that is energy
> that
> > could be spent helping get more minors out more frequently.   One of the
> > things about having frequent point release like when we had with 0.94 was
> > that we likely could have shipped some of the earlier 1.2.0rcs and fixed
> > the criticals in next point release train.
> >
> > Jon.
> >
> >> On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk  > wrote:
> >>
> >> I appreciate Elliot's voice for conservatism on released branches.
> However
> >> I don't think we're getting minor releases out the door fast enough,
> >> especially when we have nice "improvements" that apply cleanly. Users
> >> deserve to get as many of the improvements as are compatible for patch
> >> releases, according to our guidelines.
> >>
> >>> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark  > wrote:
> >>>
> >>> That one's on the edge for me. It's trying to work around a bug
> somewhere
> >>> that has caused data loss in prod. So I would lean towards it being a
> bug
> >>> fix.
> >>>
> >>> However pulling from my last few filed jiras I would say these are all
> >>> improvements:
> >>> HBASE-15166
> >>> HBASE-15146
> >>> HBASE-15137
> >>> HBASE-15083
> >>>
> >>> Some of them fixed things that we hit in production but they didn't
> >> change
> >>> correctness or cause the system to be un-usable in the normal case. So
> I
> >>> would classify them as improvements. For me I would want to backport
> only
> >>> for patch releases fixes that fixed severe issues, things that changed
> >>> correctness or caused a system to be un-usable.
> >>>
> >>> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell  >
> >>> wrote:
> >>>
>  Ok, in fairness there could be more debatable (or even not debatable)
>  changes on branch-1 as you say. Also, a difference of perspective.
> >> Would
>  you for example consider HBASE-15211 a bug fix or improvement?
> 
> > On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark  >
>  wrote:
> 
> > On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
>  andrew.purt...@gmail.com >
> > wrote:
> >
> >> The majority of changes in branch-1 that I see are bug fixes.
> >
> >
> > I think that's the point that you and I differ. For me I would
> >> classify
> > most things on branch-1 as improvements and there are very few bug
> >>> fixes.
> 
> 
> 
>  --
>  Best regards,
> 
>    - Andy
> 
>  Problems worthy of attack prove their worth by hitting back. - Piet
> >> Hein
>  (via Tom White)
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // j...@cloudera.com  // @jmhsieh
>

Re: Backporting to active branches

[Elliott Clark]

On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell 
wrote:

> I think Elliott's point of view is spot on for patch releases and
> furthermore our semver-like policy as documented expresses that
> conservatism when discussing point releases.
>

Yeah my concern was really only for patch versions. We should be super
conservative on those.

I think our policy for what to include in minor versions is just fine.
However I think that everyone agrees that we haven't been releasing minor
versions fast enough. So if we release more minor versions then each one
would be less risky.

Re: Backporting to active branches

[Andrew Purtell]

I was responding to 

(Jon) "One of the things about having frequent point release like when we had 
with 0.94"

On Feb 12, 2016, at 9:33 AM, Nick Dimiduk  wrote:

>>> One of the
>>> things about having frequent point release like when we had with 0.94 was
>>> that we likely could have shipped some of the earlier 1.2.0rcs and fixed
>>> the criticals in next point release train.
>>> 
>>> Jon.

Re: Backporting to active branches

[Andrew Purtell]

'Point release' isn't precise enough terminology. We have major, minor, and 
patch releases:

0.96 -> 0.98 or 1.0 -> 2.0 - major 
0.98.0 -> 0.98.1, or 1.0.0 -> 1.1.0 - minor
0.98.0 -> 0.98.0.1, or 1.0.0 -> 1.0.1 - patch 

I think Elliott's point of view is spot on for patch releases and furthermore 
our semver-like policy as documented expresses that conservatism when 
discussing point releases. 

For minor releases I agree with Nick. Users should benefit from improvements 
that don't break compatibility as defined by our guidelines. For example 0.98 
is the last release before region replicas. Some might be shy about upgrading 
to a release containing this major change but will definitely want perf 
improvements, operability improvements to tooling, and such. When something 
like MOB goes in we'll have another such point. 

For major releases we have given ourselves leeway to do big things, but that's 
going to be a case by case discussion, where even so we want to give users a 
way to make a smooth transition. 

> On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh  wrote:
> 
> Users also deserve to get as few new surprises as possible.  Being on the
> supporting side of this, I've come to prefer preserving minor known issues
> to having new unknown issues caused of small improvements.
> 
> I prefer the conservative approach with "improvements", and prefer that
> maint/point release just backport critical fixes, security fixes, testing
> improvements (test only flakey fixups), recovery tooling (hbck updates),
> and critical perf regression fixes.
> 
> If not getting minors out fast enough is the main concern and motivator,
> I'd argue backporting more doesn't help the problem -- that is energy that
> could be spent helping get more minors out more frequently.   One of the
> things about having frequent point release like when we had with 0.94 was
> that we likely could have shipped some of the earlier 1.2.0rcs and fixed
> the criticals in next point release train.
> 
> Jon.
> 
>> On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk  wrote:
>> 
>> I appreciate Elliot's voice for conservatism on released branches. However
>> I don't think we're getting minor releases out the door fast enough,
>> especially when we have nice "improvements" that apply cleanly. Users
>> deserve to get as many of the improvements as are compatible for patch
>> releases, according to our guidelines.
>> 
>>> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark  wrote:
>>> 
>>> That one's on the edge for me. It's trying to work around a bug somewhere
>>> that has caused data loss in prod. So I would lean towards it being a bug
>>> fix.
>>> 
>>> However pulling from my last few filed jiras I would say these are all
>>> improvements:
>>> HBASE-15166
>>> HBASE-15146
>>> HBASE-15137
>>> HBASE-15083
>>> 
>>> Some of them fixed things that we hit in production but they didn't
>> change
>>> correctness or cause the system to be un-usable in the normal case. So I
>>> would classify them as improvements. For me I would want to backport only
>>> for patch releases fixes that fixed severe issues, things that changed
>>> correctness or caused a system to be un-usable.
>>> 
>>> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell 
>>> wrote:
>>> 
 Ok, in fairness there could be more debatable (or even not debatable)
 changes on branch-1 as you say. Also, a difference of perspective.
>> Would
 you for example consider HBASE-15211 a bug fix or improvement?
 
> On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark 
 wrote:
 
> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
 andrew.purt...@gmail.com>
> wrote:
> 
>> The majority of changes in branch-1 that I see are bug fixes.
> 
> 
> I think that's the point that you and I differ. For me I would
>> classify
> most things on branch-1 as improvements and there are very few bug
>>> fixes.
 
 
 
 --
 Best regards,
 
   - Andy
 
 Problems worthy of attack prove their worth by hitting back. - Piet
>> Hein
 (via Tom White)
> 
> 
> 
> -- 
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // j...@cloudera.com // @jmhsieh

Re: Backporting to active branches

[Jonathan Hsieh]

I agree with Andrew here.

We had a good cadence with 98 -- I didn't mean to exclude.  The fast
cadence of 94/98 releases was good --  the more recent 1.x lines haven't
been as frequent.

Using the more precise terminology Andrew suggests-- if we used our new
versioning rules back in the 94/98 days, many would effectively have been
patch releases (e.g.: using snapshots as an example,  94.3, .4, .5 were
roughly patch releases, and 94.6 which intro'ed snapshots which would have
been a minor). We just didn't make it obvious to users back then.

Jon.


On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell 
wrote:

> 'Point release' isn't precise enough terminology. We have major, minor,
> and patch releases:
>
> 0.96 -> 0.98 or 1.0 -> 2.0 - major
> 0.98.0 -> 0.98.1, or 1.0.0 -> 1.1.0 - minor
> 0.98.0 -> 0.98.0.1, or 1.0.0 -> 1.0.1 - patch
>
> I think Elliott's point of view is spot on for patch releases and
> furthermore our semver-like policy as documented expresses that
> conservatism when discussing point releases.
>
> For minor releases I agree with Nick. Users should benefit from
> improvements that don't break compatibility as defined by our guidelines.
> For example 0.98 is the last release before region replicas. Some might be
> shy about upgrading to a release containing this major change but will
> definitely want perf improvements, operability improvements to tooling, and
> such. When something like MOB goes in we'll have another such point.
>
> For major releases we have given ourselves leeway to do big things, but
> that's going to be a case by case discussion, where even so we want to give
> users a way to make a smooth transition.
>
> > On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh  wrote:
> >
> > Users also deserve to get as few new surprises as possible.  Being on the
> > supporting side of this, I've come to prefer preserving minor known
> issues
> > to having new unknown issues caused of small improvements.
> >
> > I prefer the conservative approach with "improvements", and prefer that
> > maint/point release just backport critical fixes, security fixes, testing
> > improvements (test only flakey fixups), recovery tooling (hbck updates),
> > and critical perf regression fixes.
> >
> > If not getting minors out fast enough is the main concern and motivator,
> > I'd argue backporting more doesn't help the problem -- that is energy
> that
> > could be spent helping get more minors out more frequently.   One of the
> > things about having frequent point release like when we had with 0.94 was
> > that we likely could have shipped some of the earlier 1.2.0rcs and fixed
> > the criticals in next point release train.
> >
> > Jon.
> >
> >> On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk 
> wrote:
> >>
> >> I appreciate Elliot's voice for conservatism on released branches.
> However
> >> I don't think we're getting minor releases out the door fast enough,
> >> especially when we have nice "improvements" that apply cleanly. Users
> >> deserve to get as many of the improvements as are compatible for patch
> >> releases, according to our guidelines.
> >>
> >>> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark 
> wrote:
> >>>
> >>> That one's on the edge for me. It's trying to work around a bug
> somewhere
> >>> that has caused data loss in prod. So I would lean towards it being a
> bug
> >>> fix.
> >>>
> >>> However pulling from my last few filed jiras I would say these are all
> >>> improvements:
> >>> HBASE-15166
> >>> HBASE-15146
> >>> HBASE-15137
> >>> HBASE-15083
> >>>
> >>> Some of them fixed things that we hit in production but they didn't
> >> change
> >>> correctness or cause the system to be un-usable in the normal case. So
> I
> >>> would classify them as improvements. For me I would want to backport
> only
> >>> for patch releases fixes that fixed severe issues, things that changed
> >>> correctness or caused a system to be un-usable.
> >>>
> >>> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell 
> >>> wrote:
> >>>
>  Ok, in fairness there could be more debatable (or even not debatable)
>  changes on branch-1 as you say. Also, a difference of perspective.
> >> Would
>  you for example consider HBASE-15211 a bug fix or improvement?
> 
> > On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark 
>  wrote:
> 
> > On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
>  andrew.purt...@gmail.com>
> > wrote:
> >
> >> The majority of changes in branch-1 that I see are bug fixes.
> >
> >
> > I think that's the point that you and I differ. For me I would
> >> classify
> > most things on branch-1 as improvements and there are very few bug
> >>> fixes.
> 
> 
> 
>  --
>  Best regards,
> 
>    - Andy
> 
>  Problems worthy of attack prove their worth by hitting back. - Piet
> >> Hein
>  (via Tom White)
> >

Re: Backporting to active branches

[Andrew Purtell]

I think if we tell people to drop the "0." prefix from pre 1.0 versions and 
squint then it gives a good sense of what can and did happen release to 
release. 

> On Feb 12, 2016, at 10:23 AM, Jonathan Hsieh  wrote:
> 
> I agree with Andrew here.
> 
> We had a good cadence with 98 -- I didn't mean to exclude.  The fast
> cadence of 94/98 releases was good --  the more recent 1.x lines haven't
> been as frequent.
> 
> Using the more precise terminology Andrew suggests-- if we used our new
> versioning rules back in the 94/98 days, many would effectively have been
> patch releases (e.g.: using snapshots as an example,  94.3, .4, .5 were
> roughly patch releases, and 94.6 which intro'ed snapshots which would have
> been a minor). We just didn't make it obvious to users back then.
> 
> Jon.
> 
> 
> On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell 
> wrote:
> 
>> 'Point release' isn't precise enough terminology. We have major, minor,
>> and patch releases:
>> 
>> 0.96 -> 0.98 or 1.0 -> 2.0 - major
>> 0.98.0 -> 0.98.1, or 1.0.0 -> 1.1.0 - minor
>> 0.98.0 -> 0.98.0.1, or 1.0.0 -> 1.0.1 - patch
>> 
>> I think Elliott's point of view is spot on for patch releases and
>> furthermore our semver-like policy as documented expresses that
>> conservatism when discussing point releases.
>> 
>> For minor releases I agree with Nick. Users should benefit from
>> improvements that don't break compatibility as defined by our guidelines.
>> For example 0.98 is the last release before region replicas. Some might be
>> shy about upgrading to a release containing this major change but will
>> definitely want perf improvements, operability improvements to tooling, and
>> such. When something like MOB goes in we'll have another such point.
>> 
>> For major releases we have given ourselves leeway to do big things, but
>> that's going to be a case by case discussion, where even so we want to give
>> users a way to make a smooth transition.
>> 
>>> On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh  wrote:
>>> 
>>> Users also deserve to get as few new surprises as possible.  Being on the
>>> supporting side of this, I've come to prefer preserving minor known
>> issues
>>> to having new unknown issues caused of small improvements.
>>> 
>>> I prefer the conservative approach with "improvements", and prefer that
>>> maint/point release just backport critical fixes, security fixes, testing
>>> improvements (test only flakey fixups), recovery tooling (hbck updates),
>>> and critical perf regression fixes.
>>> 
>>> If not getting minors out fast enough is the main concern and motivator,
>>> I'd argue backporting more doesn't help the problem -- that is energy
>> that
>>> could be spent helping get more minors out more frequently.   One of the
>>> things about having frequent point release like when we had with 0.94 was
>>> that we likely could have shipped some of the earlier 1.2.0rcs and fixed
>>> the criticals in next point release train.
>>> 
>>> Jon.
>>> 
 On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk 
>> wrote:
 
 I appreciate Elliot's voice for conservatism on released branches.
>> However
 I don't think we're getting minor releases out the door fast enough,
 especially when we have nice "improvements" that apply cleanly. Users
 deserve to get as many of the improvements as are compatible for patch
 releases, according to our guidelines.
 
> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark 
>> wrote:
> 
> That one's on the edge for me. It's trying to work around a bug
>> somewhere
> that has caused data loss in prod. So I would lean towards it being a
>> bug
> fix.
> 
> However pulling from my last few filed jiras I would say these are all
> improvements:
> HBASE-15166
> HBASE-15146
> HBASE-15137
> HBASE-15083
> 
> Some of them fixed things that we hit in production but they didn't
 change
> correctness or cause the system to be un-usable in the normal case. So
>> I
> would classify them as improvements. For me I would want to backport
>> only
> for patch releases fixes that fixed severe issues, things that changed
> correctness or caused a system to be un-usable.
> 
> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell 
> wrote:
> 
>> Ok, in fairness there could be more debatable (or even not debatable)
>> changes on branch-1 as you say. Also, a difference of perspective.
 Would
>> you for example consider HBASE-15211 a bug fix or improvement?
>> 
>>> On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark 
>> wrote:
>> 
>>> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
>> andrew.purt...@gmail.com>
>>> wrote:
>>> 
 The majority of changes in branch-1 that I see are bug fixes.
>>> 
>>> 
>>> I think that's the point that 

Re: Backporting to active branches

[Enis Söztutar]

I am in favor of "bug fixes only" changes to the patch releases. In 1.0
release lines, we tried to stick to that, and explicitly did not backport
some nice improvements. In many occasions, we had backported some issue
thinking that it is harmless, but turned out to be a problem. So, the less
change in patch releases the better. Having said that, there are exceptions
to this rule, and it is still ok to backport "improvements" where risk vs
reward is pretty obvious.

However, I feel the pain that Nick is talking about in terms of maintaining
the backports. ALL committers should be familiar with the general
guidelines we follow so that they can judge on a patch-by-patch basis
whether to backport or not. All critical / blocker, data loss kind of
things should go to all active branches. Other bug fixes, we should again
use risk vs reward judgement.

Enis

On Fri, Feb 12, 2016 at 11:12 AM, Andrew Purtell 
wrote:

> I think if we tell people to drop the "0." prefix from pre 1.0 versions
> and squint then it gives a good sense of what can and did happen release to
> release.
>
> > On Feb 12, 2016, at 10:23 AM, Jonathan Hsieh  wrote:
> >
> > I agree with Andrew here.
> >
> > We had a good cadence with 98 -- I didn't mean to exclude.  The fast
> > cadence of 94/98 releases was good --  the more recent 1.x lines haven't
> > been as frequent.
> >
> > Using the more precise terminology Andrew suggests-- if we used our new
> > versioning rules back in the 94/98 days, many would effectively have been
> > patch releases (e.g.: using snapshots as an example,  94.3, .4, .5 were
> > roughly patch releases, and 94.6 which intro'ed snapshots which would
> have
> > been a minor). We just didn't make it obvious to users back then.
> >
> > Jon.
> >
> >
> > On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell <
> andrew.purt...@gmail.com>
> > wrote:
> >
> >> 'Point release' isn't precise enough terminology. We have major, minor,
> >> and patch releases:
> >>
> >> 0.96 -> 0.98 or 1.0 -> 2.0 - major
> >> 0.98.0 -> 0.98.1, or 1.0.0 -> 1.1.0 - minor
> >> 0.98.0 -> 0.98.0.1, or 1.0.0 -> 1.0.1 - patch
> >>
> >> I think Elliott's point of view is spot on for patch releases and
> >> furthermore our semver-like policy as documented expresses that
> >> conservatism when discussing point releases.
> >>
> >> For minor releases I agree with Nick. Users should benefit from
> >> improvements that don't break compatibility as defined by our
> guidelines.
> >> For example 0.98 is the last release before region replicas. Some might
> be
> >> shy about upgrading to a release containing this major change but will
> >> definitely want perf improvements, operability improvements to tooling,
> and
> >> such. When something like MOB goes in we'll have another such point.
> >>
> >> For major releases we have given ourselves leeway to do big things, but
> >> that's going to be a case by case discussion, where even so we want to
> give
> >> users a way to make a smooth transition.
> >>
> >>> On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh  wrote:
> >>>
> >>> Users also deserve to get as few new surprises as possible.  Being on
> the
> >>> supporting side of this, I've come to prefer preserving minor known
> >> issues
> >>> to having new unknown issues caused of small improvements.
> >>>
> >>> I prefer the conservative approach with "improvements", and prefer that
> >>> maint/point release just backport critical fixes, security fixes,
> testing
> >>> improvements (test only flakey fixups), recovery tooling (hbck
> updates),
> >>> and critical perf regression fixes.
> >>>
> >>> If not getting minors out fast enough is the main concern and
> motivator,
> >>> I'd argue backporting more doesn't help the problem -- that is energy
> >> that
> >>> could be spent helping get more minors out more frequently.   One of
> the
> >>> things about having frequent point release like when we had with 0.94
> was
> >>> that we likely could have shipped some of the earlier 1.2.0rcs and
> fixed
> >>> the criticals in next point release train.
> >>>
> >>> Jon.
> >>>
>  On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk 
> >> wrote:
> 
>  I appreciate Elliot's voice for conservatism on released branches.
> >> However
>  I don't think we're getting minor releases out the door fast enough,
>  especially when we have nice "improvements" that apply cleanly. Users
>  deserve to get as many of the improvements as are compatible for patch
>  releases, according to our guidelines.
> 
> > On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark 
> >> wrote:
> >
> > That one's on the edge for me. It's trying to work around a bug
> >> somewhere
> > that has caused data loss in prod. So I would lean towards it being a
> >> bug
> > fix.
> >
> > However pulling from my last few filed jiras I would say these are
> all
> > improvements:
> > 

Re: Backporting to active branches

[Nick Dimiduk]

I appreciate Elliot's voice for conservatism on released branches. However
I don't think we're getting minor releases out the door fast enough,
especially when we have nice "improvements" that apply cleanly. Users
deserve to get as many of the improvements as are compatible for patch
releases, according to our guidelines.

On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark  wrote:

> That one's on the edge for me. It's trying to work around a bug somewhere
> that has caused data loss in prod. So I would lean towards it being a bug
> fix.
>
> However pulling from my last few filed jiras I would say these are all
> improvements:
> HBASE-15166
> HBASE-15146
> HBASE-15137
> HBASE-15083
>
> Some of them fixed things that we hit in production but they didn't change
> correctness or cause the system to be un-usable in the normal case. So I
> would classify them as improvements. For me I would want to backport only
> for patch releases fixes that fixed severe issues, things that changed
> correctness or caused a system to be un-usable.
>
> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell 
> wrote:
>
> > Ok, in fairness there could be more debatable (or even not debatable)
> > changes on branch-1 as you say. Also, a difference of perspective. Would
> > you for example consider HBASE-15211 a bug fix or improvement?
> >
> > On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark 
> wrote:
> >
> > > On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
> > andrew.purt...@gmail.com>
> > > wrote:
> > >
> > > > The majority of changes in branch-1 that I see are bug fixes.
> > >
> > >
> > > I think that's the point that you and I differ. For me I would classify
> > > most things on branch-1 as improvements and there are very few bug
> fixes.
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>

Re: Backporting to active branches

[Jonathan Hsieh]

Users also deserve to get as few new surprises as possible.  Being on the
supporting side of this, I've come to prefer preserving minor known issues
to having new unknown issues caused of small improvements.

I prefer the conservative approach with "improvements", and prefer that
maint/point release just backport critical fixes, security fixes, testing
improvements (test only flakey fixups), recovery tooling (hbck updates),
and critical perf regression fixes.

If not getting minors out fast enough is the main concern and motivator,
I'd argue backporting more doesn't help the problem -- that is energy that
could be spent helping get more minors out more frequently.   One of the
things about having frequent point release like when we had with 0.94 was
that we likely could have shipped some of the earlier 1.2.0rcs and fixed
the criticals in next point release train.

Jon.

On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk  wrote:

> I appreciate Elliot's voice for conservatism on released branches. However
> I don't think we're getting minor releases out the door fast enough,
> especially when we have nice "improvements" that apply cleanly. Users
> deserve to get as many of the improvements as are compatible for patch
> releases, according to our guidelines.
>
> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark  wrote:
>
> > That one's on the edge for me. It's trying to work around a bug somewhere
> > that has caused data loss in prod. So I would lean towards it being a bug
> > fix.
> >
> > However pulling from my last few filed jiras I would say these are all
> > improvements:
> > HBASE-15166
> > HBASE-15146
> > HBASE-15137
> > HBASE-15083
> >
> > Some of them fixed things that we hit in production but they didn't
> change
> > correctness or cause the system to be un-usable in the normal case. So I
> > would classify them as improvements. For me I would want to backport only
> > for patch releases fixes that fixed severe issues, things that changed
> > correctness or caused a system to be un-usable.
> >
> > On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell 
> > wrote:
> >
> > > Ok, in fairness there could be more debatable (or even not debatable)
> > > changes on branch-1 as you say. Also, a difference of perspective.
> Would
> > > you for example consider HBASE-15211 a bug fix or improvement?
> > >
> > > On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark 
> > wrote:
> > >
> > > > On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
> > > andrew.purt...@gmail.com>
> > > > wrote:
> > > >
> > > > > The majority of changes in branch-1 that I see are bug fixes.
> > > >
> > > >
> > > > I think that's the point that you and I differ. For me I would
> classify
> > > > most things on branch-1 as improvements and there are very few bug
> > fixes.
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >- Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// j...@cloudera.com // @jmhsieh

Re: Backporting to active branches

[Andrew Purtell]

The criteria we use for branches >= 1.0 I think addresses this concern.
Remember: For 0.98, each 0.98.x is a new _minor_ release. For each 1.1.x
each new release is a _patch_ release. So it's likely that features make it
in to 0.98, because - new minors; but unlikely features make it into 1.1.x,
because - only a patch release.

On Thu, Feb 11, 2016 at 10:33 AM, Elliott Clark  wrote:

> I disagree. We should encourage people to keep up with releases otherwise
> things will become un-tenable.
> I would vote that we should push back critical and blocker bug fixes to 1.1
> but small fixes should go in the active 1.X branch. The number of patches
> that we backport makes the "stable" branches less stable.
>
> On Thu, Feb 11, 2016 at 9:13 AM, Andrew Purtell 
> wrote:
>
> > Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About
> > once or twice a month I sweep branch-1 for changes suitable for picking
> > back further. You have asked for patches for branch-1.1 to be posted to
> > respective issues. I can stop with that or do the same with 1.1 that I've
> > done with 0.98: if the patch applies cleanly or with minor fixup,
> relevant
> > sampled subset of unit tests pass, and the API compat checker says ok,
> then
> > I apply and push it directly.
> >
> > > On Feb 11, 2016, at 9:03 AM, Nick Dimiduk  wrote:
> > >
> > > Heya folks,
> > >
> > > I'm sorry to say branch-1.1 is falling behind in terms of backporting
> > fixes
> > > and performance improvements. Anything that's not a new feature and
> that
> > > doesn't break our compatibility guidelines is explicitly acceptable and
> > > *should* be backported to the active release branches, 0.98 and
> > branch-1.1.
> > > Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I don't
> > > have the bandwidth to pursue the commit logs so diligently.
> > >
> > > Let's change our relationship slightly, dev community. If you're
> working
> > on
> > > a fix, please also post a patch for branch-1.1. By policy, that's
> > anything
> > > that's not a new feature. I'll veto anything that doesn't hold the
> > > compatibility guidelines. The other PMC know the guidelines as well, so
> > if
> > > you're unsure you don't even have to wait on me -- ask any of them. You
> > can
> > > even guess whether I'm going to veto it through a quick review of our
> > > guidelines [0] and by running your patch through the compatibility
> > checker
> > > [1]. It only takes a few extra minutes and it will ensure a reasonable
> > > shelf-life for our release lines.
> > >
> > > Thanks a lot for all your effort,
> > > Nick
> > >
> > > [0]: http://hbase.apache.org/book.html#hbase.versioning.post10
> > > [1]:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master
> >
>



-- 
Best regards,

   - Andy

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

Re: Backporting to active branches

[Stack]

On Thu, Feb 11, 2016 at 9:03 AM, Nick Dimiduk  wrote:

> ...
> Let's change our relationship slightly, dev community. If you're working on
> a fix, please also post a patch for branch-1.1.


It is a bit tough. That'd be a patch for four branches (at least), three of
which have diverged in key areas (master, branch-1 and branch-1.2, and
branch-1.1). Each patch takes a bit of time, especially if some fixup
needed, and then, if doing the application, there is watching the build
subsequently to see if my application broke the build (which a seemingly
innocuous application does with some regularity). A critical fix should be
done in all branches, but for less-than-critical, I'd be for encouraging
folks to (rolling) upgrade to get new performance/feature?

Andrew's monthly sweep is the way to do it best IMO. When done, there is a
singular rather than a fractured focus and he's making the call what makes
it in and what doesn't. Takes time though.

St.Ack





> By policy, that's anything
> that's not a new feature. I'll veto anything that doesn't hold the
> compatibility guidelines. The other PMC know the guidelines as well, so if
> you're unsure you don't even have to wait on me -- ask any of them. You can
> even guess whether I'm going to veto it through a quick review of our
> guidelines [0] and by running your patch through the compatibility checker
> [1]. It only takes a few extra minutes and it will ensure a reasonable
> shelf-life for our release lines.
>
> Thanks a lot for all your effort,
> Nick
>
> [0]: http://hbase.apache.org/book.html#hbase.versioning.post10
> [1]:
>
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master
>

Re: Backporting to active branches

[Elliott Clark]

On Thu, Feb 11, 2016 at 11:10 AM, Andrew Purtell 
wrote:

> later versions of 0.98 are more stable


I would assert that to be because less and less things are applying now.

Every time we have tried a new patch version of 1.0 ( We haven't really
tried any 1.1 since we've been on 1.2) there were new issues. I have yet to
try a new patch version that didn't have the same issues I would associate
with a minor version.

Re: Backporting to active branches

[Andrew Purtell]

I would also quibble about this:

> The number of patches that we backport makes the "stable" branches less
stable.

At least in our production settings, later versions of 0.98 are more stable
and perform better than earlier ones as a rule. My experience refutes the
above claim, but YMMV


On Thu, Feb 11, 2016 at 11:00 AM, Andrew Purtell 
wrote:

> The criteria we use for branches >= 1.0 I think addresses this concern.
> Remember: For 0.98, each 0.98.x is a new _minor_ release. For each 1.1.x
> each new release is a _patch_ release. So it's likely that features make it
> in to 0.98, because - new minors; but unlikely features make it into 1.1.x,
> because - only a patch release.
>
> On Thu, Feb 11, 2016 at 10:33 AM, Elliott Clark  wrote:
>
>> I disagree. We should encourage people to keep up with releases otherwise
>> things will become un-tenable.
>> I would vote that we should push back critical and blocker bug fixes to
>> 1.1
>> but small fixes should go in the active 1.X branch. The number of patches
>> that we backport makes the "stable" branches less stable.
>>
>> On Thu, Feb 11, 2016 at 9:13 AM, Andrew Purtell > >
>> wrote:
>>
>> > Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About
>> > once or twice a month I sweep branch-1 for changes suitable for picking
>> > back further. You have asked for patches for branch-1.1 to be posted to
>> > respective issues. I can stop with that or do the same with 1.1 that
>> I've
>> > done with 0.98: if the patch applies cleanly or with minor fixup,
>> relevant
>> > sampled subset of unit tests pass, and the API compat checker says ok,
>> then
>> > I apply and push it directly.
>> >
>> > > On Feb 11, 2016, at 9:03 AM, Nick Dimiduk 
>> wrote:
>> > >
>> > > Heya folks,
>> > >
>> > > I'm sorry to say branch-1.1 is falling behind in terms of backporting
>> > fixes
>> > > and performance improvements. Anything that's not a new feature and
>> that
>> > > doesn't break our compatibility guidelines is explicitly acceptable
>> and
>> > > *should* be backported to the active release branches, 0.98 and
>> > branch-1.1.
>> > > Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I
>> don't
>> > > have the bandwidth to pursue the commit logs so diligently.
>> > >
>> > > Let's change our relationship slightly, dev community. If you're
>> working
>> > on
>> > > a fix, please also post a patch for branch-1.1. By policy, that's
>> > anything
>> > > that's not a new feature. I'll veto anything that doesn't hold the
>> > > compatibility guidelines. The other PMC know the guidelines as well,
>> so
>> > if
>> > > you're unsure you don't even have to wait on me -- ask any of them.
>> You
>> > can
>> > > even guess whether I'm going to veto it through a quick review of our
>> > > guidelines [0] and by running your patch through the compatibility
>> > checker
>> > > [1]. It only takes a few extra minutes and it will ensure a reasonable
>> > > shelf-life for our release lines.
>> > >
>> > > Thanks a lot for all your effort,
>> > > Nick
>> > >
>> > > [0]: http://hbase.apache.org/book.html#hbase.versioning.post10
>> > > [1]:
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master
>> >
>>
>
>
>
> --
> 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)

Re: Backporting to active branches

[Andrew Purtell]

> I would assert that to be because less and less things are applying now.

​I'm sure that's true as well (smile)
​


On Thu, Feb 11, 2016 at 11:32 AM, Elliott Clark  wrote:

> On Thu, Feb 11, 2016 at 11:10 AM, Andrew Purtell 
> wrote:
>
> > later versions of 0.98 are more stable
>
>
> I would assert that to be because less and less things are applying now.
>
> Every time we have tried a new patch version of 1.0 ( We haven't really
> tried any 1.1 since we've been on 1.2) there were new issues. I have yet to
> try a new patch version that didn't have the same issues I would associate
> with a minor version.
>



-- 
Best regards,

   - Andy

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

Re: Backporting to active branches

[Josh Elser]

Stack wrote:

...
>  Let's change our relationship slightly, dev community. If you're working on
>  a fix, please also post a patch for branch-1.1.



It is a bit tough. That'd be a patch for four branches (at least), three of
which have diverged in key areas (master, branch-1 and branch-1.2, and
branch-1.1). Each patch takes a bit of time, especially if some fixup
needed, and then, if doing the application, there is watching the build
subsequently to see if my application broke the build (which a seemingly
innocuous application does with some regularity). A critical fix should be
done in all branches, but for less-than-critical, I'd be for encouraging
folks to (rolling) upgrade to get new performance/feature?


It's a slippery slope trying to decide what has merits to get backported 
as well. After meeting compatibility guarantees, how do you decide if 
some change if critical enough to be considered for the non-EOL'ed 1.x 
branches?


Given that there's only now a 1.2.0 release in the works, it's also kind 
of crappy to try to restrict what can go out on a 1.1. I'm all for 
release early/often, but that needs to be measured against the cycles to 
make those new major/minor releases (so that we can subsequently 
encourage the community to adopt those new releases).

Re: Backporting to active branches

[Elliott Clark]

That one's on the edge for me. It's trying to work around a bug somewhere
that has caused data loss in prod. So I would lean towards it being a bug
fix.

However pulling from my last few filed jiras I would say these are all
improvements:
HBASE-15166
HBASE-15146
HBASE-15137
HBASE-15083

Some of them fixed things that we hit in production but they didn't change
correctness or cause the system to be un-usable in the normal case. So I
would classify them as improvements. For me I would want to backport only
for patch releases fixes that fixed severe issues, things that changed
correctness or caused a system to be un-usable.

On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell  wrote:

> Ok, in fairness there could be more debatable (or even not debatable)
> changes on branch-1 as you say. Also, a difference of perspective. Would
> you for example consider HBASE-15211 a bug fix or improvement?
>
> On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark  wrote:
>
> > On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
> andrew.purt...@gmail.com>
> > wrote:
> >
> > > The majority of changes in branch-1 that I see are bug fixes.
> >
> >
> > I think that's the point that you and I differ. For me I would classify
> > most things on branch-1 as improvements and there are very few bug fixes.
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: Backporting to active branches

[Andrew Purtell]

I'd also encourage RMs to make occasional (I try monthly) sweeps of upstream 
branch history to get a lay of the land and identify changes you think should 
be in your RC but didn't get there by commit - and pick those back if so. Allow 
an extra few days when scheduling time to work on that next RC. 

> On Feb 11, 2016, at 1:13 PM, Andrew Purtell  wrote:
> 
> The majority of changes in branch-1 that I see are bug fixes. Only committer 
> attention and bandwidth prevents application to all places. A few are new 
> features or bug fixes that break APIs or change behavior in a manner 
> unsuitable for a patch release. Spotting those isn't hard. Finally, it's true 
> as change application rate increases so does entropy, so occasional test 
> failures or reverts due to issues found during a RC are inevitable. I don't 
> think any rules or process can be superior to committer case by case best 
> judgement. Likewise, PMC attention to the changes incorporated in a release 
> candidate. 
> 
>> On Feb 11, 2016, at 12:42 PM, Josh Elser  wrote:
>> 
>> Stack wrote:
 ...
> Let's change our relationship slightly, dev community. If you're working 
> on
> a fix, please also post a patch for branch-1.1.
>>> 
>>> 
>>> It is a bit tough. That'd be a patch for four branches (at least), three of
>>> which have diverged in key areas (master, branch-1 and branch-1.2, and
>>> branch-1.1). Each patch takes a bit of time, especially if some fixup
>>> needed, and then, if doing the application, there is watching the build
>>> subsequently to see if my application broke the build (which a seemingly
>>> innocuous application does with some regularity). A critical fix should be
>>> done in all branches, but for less-than-critical, I'd be for encouraging
>>> folks to (rolling) upgrade to get new performance/feature?
>> 
>> It's a slippery slope trying to decide what has merits to get backported as 
>> well. After meeting compatibility guarantees, how do you decide if some 
>> change if critical enough to be considered for the non-EOL'ed 1.x branches?
>> 
>> Given that there's only now a 1.2.0 release in the works, it's also kind of 
>> crappy to try to restrict what can go out on a 1.1. I'm all for release 
>> early/often, but that needs to be measured against the cycles to make those 
>> new major/minor releases (so that we can subsequently encourage the 
>> community to adopt those new releases).

Re: Backporting to active branches

[Andrew Purtell]

The majority of changes in branch-1 that I see are bug fixes. Only committer 
attention and bandwidth prevents application to all places. A few are new 
features or bug fixes that break APIs or change behavior in a manner unsuitable 
for a patch release. Spotting those isn't hard. Finally, it's true as change 
application rate increases so does entropy, so occasional test failures or 
reverts due to issues found during a RC are inevitable. I don't think any rules 
or process can be superior to committer case by case best judgement. Likewise, 
PMC attention to the changes incorporated in a release candidate. 

> On Feb 11, 2016, at 12:42 PM, Josh Elser  wrote:
> 
> Stack wrote:
>>> ...
>>> >  Let's change our relationship slightly, dev community. If you're working 
>>> > on
>>> >  a fix, please also post a patch for branch-1.1.
>> 
>> 
>> It is a bit tough. That'd be a patch for four branches (at least), three of
>> which have diverged in key areas (master, branch-1 and branch-1.2, and
>> branch-1.1). Each patch takes a bit of time, especially if some fixup
>> needed, and then, if doing the application, there is watching the build
>> subsequently to see if my application broke the build (which a seemingly
>> innocuous application does with some regularity). A critical fix should be
>> done in all branches, but for less-than-critical, I'd be for encouraging
>> folks to (rolling) upgrade to get new performance/feature?
> 
> It's a slippery slope trying to decide what has merits to get backported as 
> well. After meeting compatibility guarantees, how do you decide if some 
> change if critical enough to be considered for the non-EOL'ed 1.x branches?
> 
> Given that there's only now a 1.2.0 release in the works, it's also kind of 
> crappy to try to restrict what can go out on a 1.1. I'm all for release 
> early/often, but that needs to be measured against the cycles to make those 
> new major/minor releases (so that we can subsequently encourage the community 
> to adopt those new releases).

Re: Backporting to active branches

[Elliott Clark]

On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell 
wrote:

> The majority of changes in branch-1 that I see are bug fixes.


I think that's the point that you and I differ. For me I would classify
most things on branch-1 as improvements and there are very few bug fixes.

Re: Backporting to active branches

[Andrew Purtell]

Ok, in fairness there could be more debatable (or even not debatable)
changes on branch-1 as you say. Also, a difference of perspective. Would
you for example consider HBASE-15211 a bug fix or improvement?

On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark  wrote:

> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell 
> wrote:
>
> > The majority of changes in branch-1 that I see are bug fixes.
>
>
> I think that's the point that you and I differ. For me I would classify
> most things on branch-1 as improvements and there are very few bug fixes.
>



-- 
Best regards,

   - Andy

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

Re: Backporting to active branches

[Andrew Purtell]

Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About once or 
twice a month I sweep branch-1 for changes suitable for picking back further. 
You have asked for patches for branch-1.1 to be posted to respective issues. I 
can stop with that or do the same with 1.1 that I've done with 0.98: if the 
patch applies cleanly or with minor fixup, relevant sampled subset of unit 
tests pass, and the API compat checker says ok, then I apply and push it 
directly. 

> On Feb 11, 2016, at 9:03 AM, Nick Dimiduk  wrote:
> 
> Heya folks,
> 
> I'm sorry to say branch-1.1 is falling behind in terms of backporting fixes
> and performance improvements. Anything that's not a new feature and that
> doesn't break our compatibility guidelines is explicitly acceptable and
> *should* be backported to the active release branches, 0.98 and branch-1.1.
> Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I don't
> have the bandwidth to pursue the commit logs so diligently.
> 
> Let's change our relationship slightly, dev community. If you're working on
> a fix, please also post a patch for branch-1.1. By policy, that's anything
> that's not a new feature. I'll veto anything that doesn't hold the
> compatibility guidelines. The other PMC know the guidelines as well, so if
> you're unsure you don't even have to wait on me -- ask any of them. You can
> even guess whether I'm going to veto it through a quick review of our
> guidelines [0] and by running your patch through the compatibility checker
> [1]. It only takes a few extra minutes and it will ensure a reasonable
> shelf-life for our release lines.
> 
> Thanks a lot for all your effort,
> Nick
> 
> [0]: http://hbase.apache.org/book.html#hbase.versioning.post10
> [1]:
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master

Backporting to active branches

[Nick Dimiduk]

Heya folks,

I'm sorry to say branch-1.1 is falling behind in terms of backporting fixes
and performance improvements. Anything that's not a new feature and that
doesn't break our compatibility guidelines is explicitly acceptable and
*should* be backported to the active release branches, 0.98 and branch-1.1.
Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I don't
have the bandwidth to pursue the commit logs so diligently.

Let's change our relationship slightly, dev community. If you're working on
a fix, please also post a patch for branch-1.1. By policy, that's anything
that's not a new feature. I'll veto anything that doesn't hold the
compatibility guidelines. The other PMC know the guidelines as well, so if
you're unsure you don't even have to wait on me -- ask any of them. You can
even guess whether I'm going to veto it through a quick review of our
guidelines [0] and by running your patch through the compatibility checker
[1]. It only takes a few extra minutes and it will ensure a reasonable
shelf-life for our release lines.

Thanks a lot for all your effort,
Nick

[0]: http://hbase.apache.org/book.html#hbase.versioning.post10
[1]:
https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master

Re: Backporting to active branches

[Elliott Clark]

I disagree. We should encourage people to keep up with releases otherwise
things will become un-tenable.
I would vote that we should push back critical and blocker bug fixes to 1.1
but small fixes should go in the active 1.X branch. The number of patches
that we backport makes the "stable" branches less stable.

On Thu, Feb 11, 2016 at 9:13 AM, Andrew Purtell 
wrote:

> Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About
> once or twice a month I sweep branch-1 for changes suitable for picking
> back further. You have asked for patches for branch-1.1 to be posted to
> respective issues. I can stop with that or do the same with 1.1 that I've
> done with 0.98: if the patch applies cleanly or with minor fixup, relevant
> sampled subset of unit tests pass, and the API compat checker says ok, then
> I apply and push it directly.
>
> > On Feb 11, 2016, at 9:03 AM, Nick Dimiduk  wrote:
> >
> > Heya folks,
> >
> > I'm sorry to say branch-1.1 is falling behind in terms of backporting
> fixes
> > and performance improvements. Anything that's not a new feature and that
> > doesn't break our compatibility guidelines is explicitly acceptable and
> > *should* be backported to the active release branches, 0.98 and
> branch-1.1.
> > Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I don't
> > have the bandwidth to pursue the commit logs so diligently.
> >
> > Let's change our relationship slightly, dev community. If you're working
> on
> > a fix, please also post a patch for branch-1.1. By policy, that's
> anything
> > that's not a new feature. I'll veto anything that doesn't hold the
> > compatibility guidelines. The other PMC know the guidelines as well, so
> if
> > you're unsure you don't even have to wait on me -- ask any of them. You
> can
> > even guess whether I'm going to veto it through a quick review of our
> > guidelines [0] and by running your patch through the compatibility
> checker
> > [1]. It only takes a few extra minutes and it will ensure a reasonable
> > shelf-life for our release lines.
> >
> > Thanks a lot for all your effort,
> > Nick
> >
> > [0]: http://hbase.apache.org/book.html#hbase.versioning.post10
> > [1]:
> >
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master
>