hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [VOTE] Release candidate 0.20.203.0-rc0
Date Mon, 02 May 2011 19:16:31 GMT
On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley <omalley@apache.org> wrote:
> I think everything is ready to go on the 0.20.203.0 release. It includes security and
a lot of improvements in the capacity scheduler and JobTracker.
>
> Should we release http://people.apache.org/~omalley/hadoop-0.20.203.0-rc0/?
>

Based on the discussion I still have the following questions:

1. Does this release replace subsequent releases from branch-0.20? Ie
is the goal to replace the 0.20.3 or 0.20.4 release with releases from
the branch-0.20-security branches?  If not, where does this release
fit in?  If so, I think we need to do the following before releasing
from branch-0.20-security:

- Make sure branch-0.20-security-203 contains the patches from 0.20.2,
since this branch is based on 0.20.1 it's not clear that it doesn't
regress against the current stable 0.20 release. Perhaps the best way
to do this is via a rebase.

- Make sure branch-0.20-security-203 (and future 0.20 based release
branches) contain the patches that were checked in for 0.20.3 and
0.20.4. These branches contain important bug fixes (eg HDFS-1258,
HDFS-909, etc) that are not present in this branch, and should be. The
expectation of people that checked in patches to branch-0.20 and the
users who filed the jiras is that they be fixed in the next stable
release.

- Remove the 0.20.3 and 0.20.4 fix versions from jira to make it clear
what the next release is.


2. What are the compatibility implications?  Specifically, do we need
to block the next major release (0.22) on getting patches in this
release committed to trunk?  Should the pace of major version releases
be slowed down by minor version releases?


3. Patches normally go through jira, get reviewed, committed to trunk,
and then merged to a release branch.  Why not use the same process
here?  I'm concerned that we're setting a precedent that patches don't
need to be reviewed and voted on.


Given that we're releasing common, hdfs and mapreduce perhaps general@
is a better place than common-dev@ for release discussion.

Thanks,
Eli

Mime
View raw message