hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: [DISCUSS] More new feature backports to 0.94.
Date Sat, 02 Mar 2013 02:25:00 GMT
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 <enis.soz@gmail.com>:
> 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 <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
>>

Mime
View raw message