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 <jean-m...@spaggiari.org> 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 <enis....@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 <la...@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 <j...@cloudera.com> >>> To: dev@hbase.apache.org; lars hofhansl <la...@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 <la...@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 <j...@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 >>> > // j...@cloudera.com >>> > >>> >>> >>> >>> -- >>> // Jonathan Hsieh (shay) >>> // Software Engineer, Cloudera >>> // j...@cloudera.com >>>
