I did mean "stablizing". What I was trying to point is that stuff we backport might stabilize HBase.
________________________________ From: Ted Yu <[email protected]> To: [email protected]; lars hofhansl <[email protected]> Sent: Friday, March 1, 2013 7:30 PM Subject: Re: [DISCUSS] More new feature backports to 0.94. bq. That is only if we do not backport stabilizing "features". Did you mean destabilizing above :-) My preference is option #1. With option #2, the community would be dealing with one more branch which would increase the amount of work validating each release candidate. To me, the difference between option #2 and the upcoming release candidates of 0.95 would blur. Cheers On Fri, Mar 1, 2013 at 7:24 PM, lars hofhansl <[email protected]> wrote: > That is only if we do not backport stabilizing "features". There is an > "opportunity cost" to be paid if we take a too rigorous approach too. > > Take > for example table-locks (which prompted this discussion). With that in > place we can do safe online schema changes (that won't fail and leave > the table in an undefined state when a concurrent split happens), it > also allows for online merge. > > Now, is that a destabilizing > "feature", or will it make HBase more stable and hence is an > "improvement"? Depends on viewpoint, doesn't it? > -- Lars > > > ________________________________ > From: Jean-Marc Spaggiari <[email protected]> > To: [email protected] > Sent: Friday, March 1, 2013 7:12 PM > Subject: Re: [DISCUSS] More new feature backports to 0.94. > > @Lars: No, not any concern about anything already backported. Just a > preference to #2 because it seems to make things more stable and > easier to manage. New feature = new release. Given new sub-releases > are for fixes and improvements, but not new features. Also, if we > backport a feature in one or many previous releases, we will have to > backport also all the fixes each time there will be an issue. So we > will have more maintenant work on previous releases. > > 2013/3/1 Enis Söztutar <[email protected]>: > > 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] > >> >>> > >> >
