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.
I don't think it is a debate about feature vs bug fix -- I've been trying
to make a general case about major feature backports.   I agree that we are
basically on the same page for the general case.    I've been using some of
the current candidate features as examples but I'm really trying to focus
on defining a general "finished" condition early-on for big backports
(bullet points that would be highlights of the next release), and to
express the need for higher scrutiny on these commits.  I'll post specific
details for each proposal in the appropriate jira.

In the specific case, I actually do want the table locks, but only after
they are done and have some evidence of stability.   I would much rather
have known bugs with known workarounds instead of unknown issues introduced
by a backported feature, and would like to avoid hackery introduced by
compatibility bugs fire drills.

The points I'm trying to make about 0.95.x is that ideally it is where the
new features get further hardened (as opposed to the stable branch).
 Ideally the release manager for that version will start gate keeping what
new major features/changes make it in there so that we have a chance of
releasing it and a 0.96 sometime soon. :)


On Sat, Mar 2, 2013 at 12:46 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> 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).
> 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

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera