Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop, mail # dev - [DISCUSSION] Release process


+
Owen OMalley 2010-03-15, 16:06
+
Jeff Hammerbacher 2010-03-15, 21:03
+
Allen Wittenauer 2010-03-24, 18:38
+
Brian Bockelman 2010-03-24, 20:27
+
Tom White 2010-03-24, 23:25
Copy link to this message
-
Re: [DISCUSSION] Release process
Jeff Hammerbacher 2010-03-25, 01:17
Hey Tom,

That sounds like a great idea. +1.

Thanks,
Jeff

On Wed, Mar 24, 2010 at 4:25 PM, Tom White <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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" <[EMAIL PROTECTED]> 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.]
> >
> >
>
+
Steve Loughran 2010-03-25, 13:22
+
Stack 2010-03-26, 19:10
+
Chris Douglas 2010-03-27, 00:03
+
Steve Loughran 2010-03-29, 16:23
+
Owen OMalley 2010-03-26, 18:43
+
Tom White 2010-03-27, 00:26
+
Doug Cutting 2010-03-30, 22:40
+
Chris K Wensel 2010-03-30, 23:04
+
Owen OMalley 2010-03-31, 03:22
+
Cosmin Lehene 2010-03-31, 09:38
+
Allen Wittenauer 2010-03-31, 11:42
+
Doug Cutting 2010-03-31, 16:06
+
Amr Awadallah 2010-03-31, 20:34
+
Doug Cutting 2010-03-31, 16:04
+
Konstantin Shvachko 2010-03-31, 17:13
+
Tom White 2010-03-31, 18:44
+
Doug Cutting 2010-03-31, 21:19
+
Konstantin Shvachko 2010-04-01, 01:29
+
Andrew Purtell 2010-04-01, 16:33
+
Chris K Wensel 2010-04-01, 17:11
+
Doug Cutting 2010-04-01, 17:18
+
Jay Booth 2010-04-01, 17:36
+
Chris Douglas 2010-04-01, 17:38
+
Doug Cutting 2010-04-01, 17:50
+
Todd Lipcon 2010-04-01, 18:26
+
Doug Cutting 2010-04-01, 18:44
+
Chris Douglas 2010-04-01, 20:59
+
Doug Cutting 2010-04-01, 21:38
+
Chris Douglas 2010-04-02, 02:23
+
Doug Cutting 2010-04-02, 17:08
+
Daniel Templeton 2010-04-02, 13:52
+
Chris Douglas 2010-04-05, 19:04
+
Chris K Wensel 2010-04-05, 21:16
+
Chris Douglas 2010-04-05, 21:54
+
Chris K Wensel 2010-04-06, 00:06
+
Allen Wittenauer 2010-04-06, 01:19
+
Steve Loughran 2010-04-06, 13:02
+
Allen Wittenauer 2010-04-06, 16:00
+
Doug Cutting 2010-04-06, 19:05
+
Chris Douglas 2010-04-06, 21:08
+
Steve Loughran 2010-04-06, 12:55
+
Mattmann, Chris A 2010-04-01, 18:24
+
Owen OMalley 2010-04-02, 05:33
+
Doug Cutting 2010-04-02, 16:09
+
Konstantin Boudnik 2010-03-26, 18:13
+
Allen Wittenauer 2010-04-01, 21:31
+
Mattmann, Chris A 2010-04-01, 21:36
+
Amr Awadallah 2010-04-02, 04:05
+
Dhruba Borthakur 2010-04-02, 04:31