Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB