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


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