hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@yahoo-inc.com>
Subject Re: [DISCUSSION] Release process
Date Fri, 26 Mar 2010 18:13:53 GMT
On Wed, Mar 24, 2010 at 01:27PM, Brian Bockelman wrote:
> 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.

I can see how the different criteria of patch acceptance might be in incentive
for different patch sets between unstable and stable releases. Thus, features
will have to be manually tracked and ported between releases.

Cos

> 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