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

Switch to Plain View
HBase, mail # dev - [DISCUSS] More new feature backports to 0.94.


+
Jonathan Hsieh 2013-03-01, 16:31
+
lars hofhansl 2013-03-01, 19:00
+
Elliott Clark 2013-03-01, 22:43
+
Jean-Marc Spaggiari 2013-03-01, 23:12
+
Enis Söztutar 2013-03-02, 00:55
+
Jonathan Hsieh 2013-03-01, 23:11
+
lars hofhansl 2013-03-02, 02:10
+
Enis Söztutar 2013-03-02, 02:17
+
Jean-Marc Spaggiari 2013-03-02, 02:25
+
Ted Yu 2013-03-02, 02:24
+
Andrew Purtell 2013-03-03, 13:50
+
Ted 2013-03-03, 14:12
+
Andrew Purtell 2013-03-03, 14:38
+
Jean-Marc Spaggiari 2013-03-04, 13:41
+
Stack 2013-03-04, 21:27
+
Enis Söztutar 2013-03-04, 22:29
+
Andrew Purtell 2013-03-05, 01:57
+
Dave Wang 2013-03-01, 16:38
+
Lars Hofhansl 2013-03-02, 02:46
+
Enis Söztutar 2013-03-02, 02:54
+
Jean-Marc Spaggiari 2013-03-02, 03:12
+
lars hofhansl 2013-03-02, 03:24
+
Ted Yu 2013-03-02, 03:30
+
lars hofhansl 2013-03-02, 03:44
+
Nicolas Liochon 2013-03-02, 11:43
+
Ted 2013-03-02, 11:57
+
Jonathan Hsieh 2013-03-02, 15:36
+
lars hofhansl 2013-03-02, 16:47
+
Ted Yu 2013-03-02, 16:14
+
Jonathan Hsieh 2013-03-02, 16:26
Copy link to this message
-
Re: [DISCUSS] More new feature backports to 0.94.
lars hofhansl 2013-03-02, 20:46
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]>
To: [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).
Jon.
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.
>
>Cheers
>
>
>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

// [EMAIL PROTECTED]
+
Jonathan Hsieh 2013-03-02, 21:49
+
Stack 2013-03-02, 23:24
+
lars hofhansl 2013-03-02, 03:23
+
Lars Hofhansl 2013-03-02, 02:45