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
Copy link to this message
-
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
> > improve it more) or non-critical.
> > * Testing and hardening anecdotes have been documented in the original
> and
> > backport jira.  There has been some relatively long term testing and
> fault
> > injection testing (roughly 4-6 weeks).
> > * It will be backported in a "big bang" -- all pieces get added or none
> > will.
> >
> > This is a level I consider to be stronger than the normal testing
> expected
> > for a patch.  Ideally, something at least this level is what I would
> expect
> > for other major backports.  Do we agree on that?
> >
> > For the table locks case, there maybe some of this may be a misperception
> > in timing from my point of view.  I see a notification about this in jira
>
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]
+
lars hofhansl 2013-03-02, 20:46
+
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