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 Threaded View
Hadoop >> mail # dev >> [VOTE] Release candidate 0.20.203.0-rc0


Copy link to this message
-
Re: [VOTE] Release candidate 0.20.203.0-rc0
On Mon, May 2, 2011 at 12:16 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley <[EMAIL PROTECTED]> 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.

I just did a quick search, and these are the JIRAs that are in 0.20.2
but appear not to be in 0.20.203.0.

HADOOP-5611
HADOOP-5612
HADOOP-5623
HADOOP-5759
HADOOP-6269
HADOOP-6315
HADOOP-6386
HADOOP-6428
HADOOP-6575
HADOOP-6576
HDFS-579
HDFS-596
HDFS-723
HDFS-732
HDFS-792
MAPREDUCE-623
MAPREDUCE-1070
MAPREDUCE-1163
MAPREDUCE-1251

>
> - 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.

These JIRAs are the ones committed to the 0.20 branch (for 0.20.3) but
are not marked as being in 0.20.203.0

HADOOP-6724
HADOOP-6833
HADOOP-6881
HADOOP-6923
HADOOP-6928
HADOOP-7116
HDFS-1024
HDFS-1041
HDFS-1240
HDFS-1258
HDFS-1377
HDFS-1404
HDFS-1406
HDFS-727
HDFS-908
HDFS-909
MAPREDUCE-1280
MAPREDUCE-1407
MAPREDUCE-1734
MAPREDUCE-1832
MAPREDUCE-1880
MAPREDUCE-2262

Tom

>
> - 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
>
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