hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: [DISCUSSION] Release process
Date Thu, 01 Apr 2010 17:38:18 GMT
> My latest proposal, a 1.0 branch based on 0.20, contains two questions:
>
> 1. Should we make an Apache release that more closely corresponds to what
> folks are using in production today (and will be using for a while yet)?
>
> 2. If we're considering the 0.20 mapreduce and filesystem APIs to be 1.0
> APIs, and the new mapreduce and filesystem APIs to be 2.0 APIs, shouldn't
> our release numbering reflect that?  Release numbers are fundamentally about
> compatibility declarations.  We could instead change our compatibility rules
> to specifically mention certain release numbers, but that feels the wrong
> way around.  Since we've not yet made a 0.21 release, we still have an
> opportunity to interject a 1.0 release with the semantics folks expect: its
> public APIs are stable.
>
> If there's support for this proposal, then I'd volunteer to drive it.  I
> won't bother to pursue this unless folks think it is worthwhile, so, if you
> like it, please speak up.  While a release itself cannot be vetoed and only
> requires a simple majority, we'll need to vote which patches would be
> applied to a 1.0 branch, and those code-change votes require consensus, so,
> vetos there would stop the process.  So please also speak up if you strongly
> oppose this proposal.

Tom has volunteered to drive a 0.21 release based on trunk. Owen has
volunteered to drive the release following that, which will follow
Tom's by about six months. Doug, you're volunteering to drive a
concurrent 1.0 release based on 0.20?

What Owen and Tom have proposed- to ensure API compatibility in
releases up to the 1.0 release- has the advantage of stabilizing the
mapreduce and FileContext APIs in versions that can actually be
deployed. It will also force the dev community to address the issues
introduced by the project split, rather than continuing to focus on
0.20 by another name. Among these issues are some pretty basic tasks:
implementing a coherent packaging/deployment story, sorting out
testing and patch validation across the projects, and stabilizing
trunk. Spending the next few months voting and arguing on which
patches make it into "new" 0.20 (branched in 2008) instead of
addressing these issues is *not* progress. I strongly oppose this.

I agree with Konstantin about the viability of 0.21. While the
aforementioned, basic issues need to be addressed for both trunk and
0.21- and perhaps duplicating this work on an ancient branch is not
well spent- it is already being used. And trunk is not stable:
rebasing from trunk now will be hell for committers and contributors.
But these decisions need to be made by the release manager.

BTW- a vote to adopt the RM role outlined by the httpd project (the
long-lost origin of this thread) has not started. If not an
httpd-style RM, then what have Tom, Owen, and Doug volunteered to do?
While we're at it, perhaps the vote on adopting bylaws needs to be
restarted. -C

Mime
View raw message