hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98
Date Mon, 21 Mar 2016 20:22:57 GMT
bq. we instead focus on a releasable master


One of the hurdles to the above is that some unit tests in master are more
flaky compared to their counterparts in branch-1.

Smoothing out the flaky tests is non-trivial effort.

On Mon, Mar 21, 2016 at 12:52 PM, Gary Helmling <ghelmling@gmail.com> wrote:

> >
> > Tho based on this discussion there's a bunch of good features that users
> > want that won't fit the criteria for #1 and #2. So allowing a backport of
> > the few that can fit into the criteria shouldn't significantly affect
> > future release from trunk. This way we can have some progress on some
> > features.
> >
> >
> If we have features that don't fit criteria #1 (compatibility), then we
> need a new major release according to our semver guidelines.  Criteria #2
> (stability) I think needs to be a gating factor on any new feature coming
> in.  We need to be able to demonstrate that we're not doing any harm for
> existing users by adding new features.
> In both cases, I'm not sure we're very well served by committing new
> features to master, then back-porting to branch-1.  That means that
> whatever stabilization is happening is likely from testing on branch-1
> based releases and not master, giving more time for changes to diverge.  I
> think we would be better served by releasing early and often from master
> and not having a branch-1 at all.  That would serve as a forcing function
> to make sure that change going in to master have to stabilize while "fresh"
> before a release is made.
> For more complex efforts, it would be better to stabilize in a feature
> branch and then merge the completed effort as one.
> I think we're already boxing ourselves in by looking at 2.0 as a feature
> based release, which means it necessarily has an unbounded timeline.  That
> means we have to do backports for other features ready before then, since
> master can't be released.  If we instead focus on a releasable master, that
> should help us release large changes more incrementally, and save ourselves
> the hassle of so many backports at the same time.  Of course everyone is
> free to invest their time where they choose.  But I think if we focus on
> time-based releases instead it would be better for the project as a whole.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message