Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> [DISCUSS] More new feature backports to 0.94.

Copy link to this message
Re: [DISCUSS] More new feature backports to 0.94.
In the end, I think, boils down to the established process.
Anybody can open a jira and propose a patch. If it gets +1's from a few committers and no -1's we should commit it.
As I said on HBASE-7965, if we cannot convince Jon and Elliot that this is safe to do, we should not do it (either because Enis and I agree, or because Jon -1's it). No hard feeling either way, I hope (none from my side at least).
It seems we're mostly in agreement and just differ a bit in what constitutes a feature vs. a bug fix.

-- Lars

 From: Jonathan Hsieh <[EMAIL PROTECTED]>
Cc: lars hofhansl <[EMAIL PROTECTED]>
Sent: Saturday, March 2, 2013 8:26 AM
Subject: Re: [DISCUSS] More new feature backports to 0.94.

To be clear, a key point is that unit testing is a required but not sufficient.  I need anecdotes about system testing with at least some unexpected fault handling and stress.  If the feature is actively being developed still, go into a dev branch (git hub or svn) that eventually merges.  Some info about perf would be nice as well if that is affected.

In cases that aren't too burdensome, I would prefer consecutive individual commits to a stable branch as opposed to a single mega patch.  This of course is a case-by-case decision. (snapshots is about 80 patches.. way too burdensome).
On Sat, Mar 2, 2013 at 8:14 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

bq. I would want to see this feature come in as a big bang -- get it
>complete enough in trunk before backporting the pieces to a stable branch.
>I agree with Jon on this point.
>Porting in one big patch allows us to think through related use cases.
>Another benefit is that there wouldn't be glitch in API, in case the first
>batch of backports went into 0.94.x and the second batch goes into 0.94.x+1
>Running the feature through test suite in trunk continuously gives us time
>to discover defects before the backport.
>On Sat, Mar 2, 2013 at 7:36 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
>> In general, I have a preference against backporting  features for the
>> reasons that Enis, Elliott, and Jean-Marc consider valid.  To be clear,
>> this preference doesn't mean I am -1 to all backports onto the stable
>> apache branch.  Let's do it case-by-case; my main ask is to make major
>> backports rare and to make it the norm to require significantly more
>> evidence of testing than usual.  I will -1 a major backport that lacks this
>> evidence.  This will come up again in the future.
>> With the cases Lars proposed -- I prefer #3 (just say no) but find #1 (be
>> very careful) acceptable given higher level of evidence.  #2 (new release
>> branch) is onerous -- I'd rather we just get preview-release branches out
>> more frequently to not have deal with this.  Arguably, the reason we have
>> the preview-release branches serve the purpose of getting releases out more
>> frequently and giving a feature time to harden from a few common points.
>>  My hope is that these preview release will replace what were the 0.x.0 and
>> 0.x.1 releases from  previous versions
>> So what kind of evidence would I like to see? We can use snapshots case as
>> an example.
>> When backporting snapshots was brought up, I actually preferred that we not
>> backport that feature.  There was demand, so we agreed that we'd do it but
>> no backport it until it is "rock solid".  Here's evidence to support the
>> case that the feature and backport is solid:
>> * It's code history is publicly documented and has been available since
>> December.
>> * It's design documentation has been available for even longer.
>> * The feature is mostly additive and doesn't affect vital paths.
>> * It was tested against trunk and the later tested against a 0.94 variant
>> that is closer to the target apache branch.
>> * The version in the trunk branch has been reviewed by 5 committers.
>> * Limitations are either documented (please let me know if we should
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera