hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hammerbacher <ham...@cloudera.com>
Subject Re: [DISCUSSION] Release process
Date Thu, 25 Mar 2010 01:17:56 GMT
Hey Tom,

That sounds like a great idea. +1.

Thanks,
Jeff

On Wed, Mar 24, 2010 at 4:25 PM, Tom White <tom@cloudera.com> wrote:

> I agree that getting the release process restarted is of utmost
> importance to the project. To help make that happen I'm happy to
> volunteer to be a release manager for the next release. This will be
> the first release post-split, so there will undoubtedly be some issues
> to work out. I think the focus should be on getting an alpha release
> out, so I suggest we create a new 0.21 branch from trunk, then spend
> time fixing blockers (which will be a superset of the existing 0.21
> blockers).
>
> Cheers,
> Tom
>
> On Wed, Mar 24, 2010 at 1:27 PM, Brian Bockelman <bbockelm@cse.unl.edu>
> wrote:
> > Hey Allen,
> >
> > Your post provoked a few thoughts:
> > 1) Hadoop is a large, but relatively immature project (as in, there's
> still a lot of major features coming down the pipe).  If we wait to release
> on features, especially when there are critical bugs, we end up with a large
> number of patches between releases.  This ends up encouraging custom patch
> sets and custom distributions.
> > 2) The barrier for patch acceptance is high, especially for opportunistic
> developers.  This is a good thing for code quality, but for getting patches
> in a timely manner.  This means that there are a lot of 'mostly good'
> patches out there in JIRA which have not landed.  This again encourages
> folks to develop their own custom patch sets.
> > 3) We make only bugfixes for past minor releases, meaning the stable
> Apache release is perpetually behind in features, even features that are not
> core.
> >
> > Not sure how to best fix these things.  One possibility:
> > a) Have a stable/unstable series (0.19.x is unstable, 0.20.x is stable,
> 0.21.x is unstable).  For the unstable releases, lower the bar for code
> acceptance for less-risky patches.
> > b) Combined with a a time-based release for bugfixes (and non-dangerous
> features?) in order to keep the feature releases "fresh".
> >
> > (a) aims to tackle problems (1) and (2).  (b) aims to tackle (3).
> >
> > This might not work for everything.  If I had a goal, it would be to
> decrease the number of active distributions from 3 to 2 - otherwise you end
> up spending far too much time consensus building.
> >
> > Just a thought from an outside, relatively content observer,
> >
> > Brian
> >
> > On Mar 24, 2010, at 1:38 PM, Allen Wittenauer wrote:
> >
> >> On 3/15/10 9:06 AM, "Owen O'Malley" <oom@yahoo-inc.com> wrote:
> >>> From our 21 experience, it looks like our old release strategy is
> >>> failing.
> >>
> >>    Maybe this is a dumb question but... Are we sure it isn't the
> community
> >> failing?
> >>
> >>    From where I stand, the major committers (PMC?) have essentially
> forked
> >> Hadoop into three competing source trees.  No one appears to be
> dedicated to
> >> helping the community release because the focus is on their own tree.
>  Worse
> >> yet, two of these trees are publicly available with both sides pushing
> their
> >> own tree as vastly superior (against each other and against the official
> >> Apache branded one).
> >>
> >>    What are the next steps in getting this resolved?  Is
> >> Hadoop-as-we-know-it essentially dead?  What is going to prevent the
> fiasco
> >> that is 0.21 from impacting 0.22?
> >>
> >>    For me personally, I'm more amused than upset that 0.21 hasn't been
> >> released.  But I'm less happy that there appears to be a focus on
> feature
> >> additions rather than getting some of the 0.21 blockers settled (I'm
> >> assuming here that most of the 0.21 blockers apply to 0.22 as well).
> >>
> >>    I don't think retroactively declaring 0.20 as 1.0 is going to make
> the
> >> situation any better.  [In fact, I believe it will make it worse, since
> it
> >> gives an external impression that 0.20 is somehow stable at all levels.
>  We
> >> all know this isn't true.]
> >
> >
>

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