I think the current way of risk vs rewards analysis is working well. We will just continue doing that on a case by case basis, discussing the implications on individual issues.
On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> 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 <[email protected]> > >>> To: [email protected]; lars hofhansl <[email protected]> > >>> 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 <[email protected]> > 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 <[email protected]> > >>> > To: [email protected] > >>> > 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 > >>> > // [email protected] > >>> > > >>> > >>> > >>> > >>> -- > >>> // Jonathan Hsieh (shay) > >>> // Software Engineer, Cloudera > >>> // [email protected] > >>> >
