hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject Re: HBase releases...
Date Wed, 12 Oct 2011 06:21:29 GMT
Doing the linux release style works well if we have enough people who are
willing and able to maintain a bunch of separate branches. As it stands the
HBase community is pretty small compared to Linux, and I don't know how many
people would be willing to maintain a release - almost a full time job on
its own, leaving little time for writing code.

Maybe before we do some of the 'early' branches we get someone from the
community to volunteer to maintain it?

I'm also worried that could lead to a LOT of fracturing in releases (hence
the million and a half flavors of linux), which I feel is not all that good
for the community (though maybe good for lining people's
**cough**RedHat**cough** pockets).


>So, I am not big fan of time based releases. What I am thinking to nudge
'>feels right' point a bit sooner. :)

That is kind of what I was getting at. I wanted to formalize the 'feels
right' process, so we don't start doing massive code drops.

>Software engineers (me included) tend to want to cram as many features as
>into a release and sometimes it is good to make this tendency conscious and
>counter this a bit to avoid feature bloat. (not saying that is a problem in
HBase, just a
>general statement here).

I'm all for adding good stuff (and I can be as much a culprit as anyone ;)

>For example, what if we had branched right after coprocessors went in.
>that been useful?

That is definitely fair that we have done some solid stuff since. But CPs
are the exception, not the rule. Hence, the provision that we can vote to
keep going.

Basically, I'm also lobbying for a way to hit a 'feels right' sooner, and I
think metrics (rather than emotion) is the way to go.

-Jesse Yates

On Tue, Oct 11, 2011 at 11:19 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> I just wrote in parallel response to Jesse that I am not a big fan of
> time based releases :)
> The way you describe it it makes sense, though.
> o we'd branch at given intervals (once a week/month/quarter/whatever)
> o some releases will turn out to be good ones, users could standardize on
> those
> o we would only provide updates in a form of a new release, or maybe a dev
> and stable release
> Might be hard to get bigger features in that way; although Linux
> manages that with merge windows.
> Seems like this'd be a big shift. Hence my softer approach to just change
> a bit what 'it feels right' means.
> -- Lars
> ----- Original Message -----
> From: Todd Lipcon <todd@cloudera.com>
> To: dev@hbase.apache.org
> Cc:
> Sent: Tuesday, October 11, 2011 11:02 PM
> Subject: Re: HBase releases...
> I was discussing this with a few other contributors a while back. In
> my mind there are two ways to do it:
> a) feature based releases that we test the crap out of and decide are
> stable. We can't really do this more than once a year, I don't think.
> b) time based releases where we make few guarantees beyond "it appears
> to work". We assume that once a year or so, major users and
> distributors latch on to one of these that feels good, and start
> maintaining it as a stable/maintenance series.
> B is the Linux model. No one in their right mind runs the latest
> kernel.org in production - but certain vintages of kernel gather
> enough folks around them, pick up a stable maintainer, etc, and after
> a while become pretty rock solid. For example, 2.6.18 and 2.6.32 seem
> to be popular kernel vintages.
> I'm personally of the mind that B is the more reasonable model. Keeps
> a release train ticking all the time, allows experimental users to get
> new features fast, and avoids the burden of feeling that any release
> we do has to be perfect. It's also often hard to say what "vintage"
> will be good until it's been out in the wild for a little while - for
> example, the 0.89.20100621 dev release turned out to be pretty decent
> despite being branded as a dev release. The later releases in that
> series had some more major problems.
> The risk with the "B" model is that everyone might end up on different
> versions, making it very hard to support the user community, etc. This
> might be partially ameliorated by some clear descriptions on the
> download/release pages which delineate which are stable/recommended
> releases and which are just time-based.
> -Todd
> On Tue, Oct 11, 2011 at 10:42 PM, Jesse Yates <jesse.k.yates@gmail.com>
> wrote:
> > I see a couple other dimensions as well, and mostly they revolve around
> the
> > user community.
> >
> > If we can release more frequently, with truly stable releases, then more
> > people will be more likely to run clusters with codebases that are closer
> to
> > trunk. Therefore they will have more benefits like bug fixes and
> performance
> > increases without the worry that they are running unstable/buggy code.
> > However, there is a big 'if' here - if we can make sure that the builds
> that
> > go out frequently are really rock solid.
> >
> > I think in the past we have had a good track record with putting out
> stable
> > releases, especially given the amount of testing that people in dev are
> > doing on real, big clusters (thanks everyone!).
> >
> > This then presents the problem of maintaining a _ton_ of branches
> compounded
> > by the difficulty of adding in a sweeping feature (coprocessor-style).
> That
> > was a huge pain to integrate (awesome job getting it in - super excited
> to
> > see .92 go out with it).
> >
> > Lars, are you proposing that we stick to more of a time based schedule
> > rather than a 'it feels right' mechanism? I worry that we can get caught
> in
> > between making some really good changes and then having essentially a
> > half-baked release come out. That will hurt credibility with end users if
> we
> > say yeah, you could you release "x", but you might as well wait till
> "x+1"
> > cause some really good stuff is coming in then. Then why did we take the
> > time to release it in the first place?
> >
> > As a middle ground, maybe we can look at the number of major and minor
> > updates since the last branch and drop a cut a new release when it
> exceeds
> > some threshold. For the first couple of iterations, this would be a
> flexible
> > limit until we find what works and makes sense to maintain. Maybe this
> also
> > means developing something like "x minor changes = 1 major change, and we
> > release every Y major change" kind of formula. After that, we can use a
> > community voting process to bump the limits for exceptional cases.
> >
> > This ensures that we don't do pointless releases, but instead put out
> > versions and still minimizes the pain involved in maintaining multiple
> > branches.
> >
> > What do you think?
> >
> > -Jesse Yates
> >
> > On Tue, Oct 11, 2011 at 10:22 PM, lars hofhansl <lhofhansl@yahoo.com>
> wrote:
> >
> >> HBase 0.90 was released Jan 2011. By the time HBase 0.92 is released it
> >> will probably be close to
> >> a year between stable releases.
> >>
> >> Should we try to have more frequent, smaller releases? Maybe 3-4 a year.
> >> For example I would almost say that the performance enhancements from
> the
> >> Facebook guys would
> >> warrant a new (performance) release "shortly" after 0.92.
> >>
> >> That would hopefully reduce the time and effort needed to stabilize the
> >> releases, at the expense of having to
> >> maintain two or even three branches in addition to trunk that people
> would
> >> still be actively using.
> >>
> >> Thoughts?
> >>
> >> -- Lars
> >>
> >
> --
> Todd Lipcon
> Software Engineer, Cloudera

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