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 <bbock...@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" <o...@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.] > >
