hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Bockelman <bbock...@cse.unl.edu>
Subject Re: [DISCUSSION] Release process
Date Wed, 24 Mar 2010 20:27:20 GMT
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
View raw message