Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4E3953B0.208@apache.org>
References: <CA571B04.20E78%gkesavan@yahoo-inc.com>
 <CA5746A9.20EF7%gkesavan@yahoo-inc.com>
 <CA+4052mCWNErTWxkJ=jQWtYxbY5Pz1W_X0VYcN_fxyDz+QdHCQ@mail.gmail.com>
 <6C8A17F4-97AB-497B-83CC-BB853E842C0E@hortonworks.com>
 <645195E6D08FFB4B9D81BB747CDF051B5A0F80@CORPUSMX10A.corp.emc.com>
 <A748BB9D-3989-480D-AC9C-3BF7F3C946D8@hortonworks.com>
 <CAPn_vTsNCsG4AhQqUpkAG1_AvE+QZX_6dYxmxL7E_OZmgt9c0A@mail.gmail.com>
 <576E7EB3-3278-4A53-9482-CB8B3DAD6683@hortonworks.com>
 <CA+4052=MUj0TnXswb7x090xxsVtMEW5ES+m86viS_KUyhgSjQQ@mail.gmail.com>
 <4E3293BC.6040608@apache.org>
 <CADdVdVGzEbddvJVNezK-Nxcgp2Ef_dVb6+bu8n39Bx+rUHR=ZA@mail.gmail.com>
 <CA+z3+9Gt1o58m7BibC+HOOYb+QZx=AiVVWLPWhE5O9PoZCDy6A@mail.gmail.com>
 <4E37DF66.2050109@apache.org>
 <10525873-1AA9-40D7-8F75-A3B3BC306004@apache.org>
 <CAPn_vTtRA=tRzJan8yGJKsvLxZLa-Rm3OSysbf7jSv_W1ogGBQ@mail.gmail.com>
 <4E3953B0.208@apache.org>
From: Matt Foley <mfoley@hortonworks.com>
Date: Wed, 3 Aug 2011 14:14:29 -0700
Message-ID: 
 <CA+z3+9FUsnQV9ZJRGWEcEBZo70YSG+MHn4Ahr5OL8dzuF-=VSQ@mail.gmail.com>
Subject: Re: [VOTE] Release 0.20.204.0-rc0
To: common-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=0015175d014c58a34904a9a05b24

--0015175d014c58a34904a9a05b24
Content-Type: text/plain; charset=ISO-8859-1

>
> So, how are we doing with 0.20.204 content and trunk given the above
> proposal? Very well, in fact. Matt, Suresh and I have done a detailed
> analysis (separate email), please take a look.


Here's the analysis of changes in 204 vs trunk.  We believe that ALL the
changes in 204 are either already in trunk or do not need to be in trunk.
 Here is the list of 204 items not already in trunk, and their
categorization.

Please, if anyone thinks we've missed something, bring it to my attention
and if it isn't already in trunk we will get it into trunk as expeditiously
as possible.
Thanks,
--Matt

Not needed for trunk:
HDFS-1758. Make Web UI JSP pages thread safe. (Tanping via suresh)  (Not a
problem in trunk)
HDFS-2057. Wait time to terminate the threads causes unit tests to take
longer time. (Bharath Mundlapudi via suresh) (Not a problem in trunk)
HDFS-1878. TestHDFSServerPorts unit test failure - race condition in
FSNamesystem.close() causes NullPointerException without serious
consequence. (mattf) (not a problem in trunk)
HDFS-1842. Handle editlog opcode conflict with 0.20.203 during upgrade, by
throwing an error to indicate the editlog needs to be empty.  (suresh)
(Handled by HDFS-1824)
HDFS-2218. Disable TestHdfsProxy.testHdfsProxyInterface in automated test
suite for 0.20-security-204 release. (Matt Foley) (Not a problem in trunk)
HDFS-2044. TestQueueProcessingStatistics failing automatic test due to
timing issues. (mattf) (not a problem in trunk)
HADOOP-7459. Remove jdk-1.6.0 dependency check from rpm. (omalley) (replaced
by HDFS-2156)
HADOOP-7398. Suppress warnings about use of HADOOP_HOME. (omalley) (not a
problem in trunk)
HADOOP-7369. Fix permissions in tarball for sbin/* and libexec/* (omalley)
(not a problem in trunk)
HADOOP-7373. Fix {start,stop}-{dfs,mapred} and hadoop-daemons.sh from trying
to use the wrong bin directory. (omalley) (not a problem in trunk)
HADOOP-7475. Fix hadoop-setup-single-node.sh to reflect new layout. (eyang
via omalley) (not a problem in trunk)

Back port from trunk:
MAPREDUCE-2524. Port reduce failure reporting semantics from trunk, to fail
faulty maps more aggressively. (Thomas Graves via cdouglas)
MAPREDUCE-2479. Move distributed cache cleanup to a background task,
backporting MAPREDUCE-1568. (Robert Joseph Evans via cdouglas)
HDFS-2023. Backport of NPE for File.list and File.listFiles.  Merged ports
of HADOOP-7322, HDFS-1934, HADOOP-7342, and HDFS-2019.  (Bharath Mundlapudi
via mattf)
HADOOP-7248. Update eclipse target to generate .classpath from ivy config.
(Thomas Graves and Tom White via cdouglas) (from HADOOP-6407)
HADOOP-7274. Fix typos in IOUtils. (Jonathan Eagles via cdouglas) (from
HADOOP-7057)
HADOOP-7277. Add generation of run configurations to eclipse target.
(Jeffrey Naisbitt and Philip Zeyliger via cdouglas) (from HADOOP-5911)
HADOOP-7364. TestMiniMRDFSCaching fails if test.build.dir is set to
something other than build/test. (Thomas Graves via mahadev) (from
MAPREDUCE-2575)

Already in trunk for MRV2:
MAPREDUCE-2558. Add queue-level metrics 0.20-security branch (test fixes)
(Jeffrey Naisbitt via mahadev)
MAPREDUCE-2418. Show job errors in JobHistory page. (Siddharth Seth via
acmurthy)  (Already in MR279)
MAPREDUCE-2411. Force an exception when the queue has an invalid name or its
ACLs are misconfigured. (Dick King via cdouglas) (Already in MR279)

Waiting for MR279 merge:
MAPREDUCE-2429. Validate JVM in TaskUmbilicalProtocol. (Siddharth Seth via
acmurthy)
MAPREDUCE-2447. Fix Child.java to set Task.jvmContext sooner to avoid corner
cases in error handling. (Siddharth Seth via acmurthy)

MapReduce v1 exceptions:
MAPREDUCE-2415. Distribute the user task logs on to multiple disks.
(Bharath Mundlapudi via omalley)
MAPREDUCE-2413. TaskTracker should handle disk failures by reinitializing
itself. (Ravi Gummadi and Jagane Sundar via omalley)
MAPREDUCE-2621. TestCapacityScheduler fails with "Queue "q1" does not
exist".  (Sherry Chen via mahadev)
MAPREDUCE-2535. Fix NPE in JobClient caused by retirement. (Robert Joseph
Evans via cdouglas)
MAPREDUCE-2555. Avoid sprious logging from completedtasks. (Thomas Graves
via cdouglas)
MAPREDUCE-2443. Fix TaskAspect for TaskUmbilicalProtocol.ping(..).
(Siddharth Seth via szetszwo)


On Wed, Aug 3, 2011 at 2:02 PM, Arun C Murthy <acm@hortonworks.com> wrote:

> On Aug 2, 2011, at 4:28 AM, Steve Loughran wrote:
> > I'm getting confused about release roadmaps right now
> >
> > Is there somewhere that lists the (proposed) timetable for the 0.20.204,
> 0.20.205, 0.22, 0.23 releases?
> >
>
> Since I was among the people who started the 'security on 0.20' thread, I
> apologize for the lack of clarity on the roadmap and timelines.
>
> Eric did send out a note on the motivation for sustaining releases (
> http://s.apache.org/hadoop-sustenance-releases) - which I believe is
> important to keep Hadoop installations going. However, I accept that there
> has been very poor clarity on the process for inclusion of content to the
> sustaining releases and the timelines.
>
> Here is my proposal for the community process for sustaining releases
> moving forward:
> # The Release Manager should clearly communicate, upfront, the expected
> timeline for each upcoming release.
> # Anyone interested in contributing to the release submits a patch to
> trunk, if applicable*, and to the branch-0.20-security branch. Then talk to
> the Release Manager for inclusion via the normal process.
>
> The RM is responsible for release content, timelines and for enforcing that
> each change should have an equivalent for trunk, as applicable, before
> inclusion.
>
> If this makes sense, I'll add this to the wiki to record it.
>
> ----
>
> So, how are we doing with 0.20.204 content and trunk given the above
> proposal? Very well, in fact. Matt, Suresh and I have done a detailed
> analysis (separate email), please take a look.
>
> thanks,
> Arun
>
> *Please note the exception that we have agreed that MRv2 is the way forward
> (http://s.apache.org/mr1) , and thus, MR1 patches might not be ported
> as-is to trunk in some cases such as fixes to JobTracker/TaskTracker.
> However, this doesn't mean changes to the runtime (i.e. map task, reduce
> task, sort, shuffle etc.) are exempt from the rules proposed above.
>
>
>

--0015175d014c58a34904a9a05b24--