hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: Backporting to active branches
Date Fri, 12 Feb 2016 19:40:42 GMT
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 <andrew.purtell@gmail.com>
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 <jon@cloudera.com> 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.purtell@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 <jon@cloudera.com> 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 <ndimiduk@apache.org>
> >> 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 <eclark@apache.org>
> >> 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 <apurtell@apache.org
> >
> >>>>> 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 <eclark@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
> >>>>>> andrew.purtell@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
> >>> // jon@cloudera.com // @jmhsieh
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // jon@cloudera.com // @jmhsieh
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message