hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gray <jg...@facebook.com>
Subject RE: Development release series?
Date Thu, 20 May 2010 18:31:36 GMT
You're right.  The dev release should be more about time gating than feature gating to push
things forward and not hold back.  But things like the master fix would benefit greatly from
getting into the dev release.  It's always in the wild that people get these weird overlapping
regions, dupe assignment, WrongRegionExceptions, etc...

> -----Original Message-----
> From: Todd Lipcon [mailto:todd@cloudera.com]
> Sent: Thursday, May 20, 2010 11:20 AM
> To: dev@hbase.apache.org
> Subject: Re: Development release series?
> 
> On Thu, May 20, 2010 at 11:12 AM, Jonathan Gray <jgray@facebook.com>
> wrote:
> 
> > In principle I'm +1 on doing a development release.  I'd like to see
> it
> > happen in early June, basically at the same time we do a feature
> freeze on
> > trunk for the real release.  So any big changes that we want to get
> in to
> > the next big release should be committed to trunk at the time we cut
> the dev
> > release.
> >
> 
> I agree on June timeframe - this also lines up well with the Hadoop
> Summit
> at the end of June. A few of us are probably giving talks and it will
> be
> nice to say "these things are in development release 0.X.0" instead of
> just
> trunk
> 
> I don't think we should *quite* feature freeze for the dev releases. We
> should freeze "major" features perhaps, but I think if we introduce
> feature
> gating on these releases instead of just time gating, we'll end up not
> getting things out.
> 
> 
> >
> > It's like a very early go at an RC.  But I like calling it a dev
> release
> > rather than an RC because for us the RCs are really things we only
> put out
> > there when we expect/hope that they become the release.  In other
> projects
> > an RC is like a dev release, so doing a dev release can give us the
> best of
> > both worlds.
> >
> +1
> 
> >
> > I'm not particular about the release manager except that this person
> would
> > have veto rights on any new features for the next big release (if we
> follow
> > my above logic that trunk should be feature frozen when we cut the
> dev
> > release), so there is some power to the position though just for a
> dev
> > release.  In general I think the release manager should be a
> committer but
> > exceptions can always be made.
> >
> >
> Fair enough, I'd be happy if you or another committer were release
> manager
> as well. I was just volunteering in case no one else wanted to.
> 
> 
> 
> > We've never been a group to stick absolutely to rules like feature
> freezes,
> > and I like that, so other stuff _can_ possibly sneak in after the dev
> > release (I'm sure I'll be pushing for a few) if there is mostly
> consensus.
> >  But it's a good target/ideal to have in mind.  Getting a new feature
> out
> > into the world gives it a chance to bake before the real release.
> Just
> > thinking about this is lighting a fire under my own ass to get moving
> on
> > some of the bigger changes I'd like to get in. :)
> >
> >
> +1, can't wait for your master fixes!
> 
> -Todd
> 
> --
> Todd Lipcon
> Software Engineer, Cloudera

Mime
View raw message