Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB