Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates
 209.85.161.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1362190203.20764.YahooMailNeo@web140603.mail.bf1.yahoo.com>
References: 
 <CAAha9a3RYpAk7-OMoZjAegxTfS01QJx+sJSHv0zoz+_WvT4cVQ@mail.gmail.com>
	<1362164434.7632.YahooMailNeo@web140601.mail.bf1.yahoo.com>
	<CAAha9a3ctFrHZGvz37VQKnvSoqhfu_SEzzk6+y_nOSsebOWB4w@mail.gmail.com>
	<1362190203.20764.YahooMailNeo@web140603.mail.bf1.yahoo.com>
Date: Fri, 1 Mar 2013 18:24:50 -0800
Message-ID: 
 <CALte62wX2kB4tSJvL0ki7RRQqN1Ah26t2vxVOpYgz6jRHYZc_A@mail.gmail.com>
Subject: Re: [DISCUSS] More new feature backports to 0.94.
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org, lars hofhansl <larsh@apache.org>
Content-Type: multipart/alternative; boundary=20cf301af25f190e7704d6e7d477

--20cf301af25f190e7704d6e7d477
Content-Type: text/plain; charset=ISO-8859-1

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

On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl <larsh@apache.org> 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 <jon@cloudera.com>
> To: dev@hbase.apache.org; lars hofhansl <larsh@apache.org>
> 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 <larsh@apache.org> 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 <jon@cloudera.com>
> > To: dev@hbase.apache.org
> > 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
> > // jon@cloudera.com
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

--20cf301af25f190e7704d6e7d477--