On Fri, Mar 26, 2010 at 11:43 AM, Owen O'Malley <omal...@apache.org> wrote: > > On Mar 24, 2010, at 4:25 PM, Tom White 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). > > That's great, Tom. Thanks for stepping up. Given that you're proposing > rebasing 0.21, what is your preferred strategy? Are you going to pick a > feature freeze date? Or propose a more httpd-like process where you cut the > branch and then control what goes in?
A bit of both: I was thinking about creating a new branch soon, on a feature freeze date (in a couple of weeks or so, ideally), then deciding what the blockers are for the release. Some of the issues currently marked as 0.21 blockers may not actually block the release (e.g. a documentation improvement), and there will be other issues that will turn out to be blockers. For example, we need to be confident that the 0.21 API is compatible with the 0.20 API, so getting good JDiff output and some compatibility tests (MAPREDUCE-1637) are important IMO. > > Also note that the security work is not done in trunk. That isn't a blocker > of course, but I don't any one to have unrealistic expectations that a > rebased 0.21 would include all of the security work. (The work is done in > our Yahoo 0.20.100 branch that we should push to github soon. We will also > be forward porting the patches into trunk over the next month.) Thanks for pointing this out, Owen. One of my motivations for doing this is to exercise the post-split release process, so this should be seen as an alpha release, where some features (like security) may be incomplete or potentially unstable. And thanks for the offers to do testing (Steve and Stack), that's very helpful. I suggest we have a wiki page or similar so that folks can record the tests they ran and the cluster details for a release candidate. Cheers, Tom > > Thanks, > Owen >
