Return-Path: X-Original-To: apmail-hadoop-general-archive@minotaur.apache.org Delivered-To: apmail-hadoop-general-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 578F93D11 for ; Thu, 5 May 2011 00:22:36 +0000 (UTC) Received: (qmail 54059 invoked by uid 500); 5 May 2011 00:22:35 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 54011 invoked by uid 500); 5 May 2011 00:22:34 -0000 Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@hadoop.apache.org Delivered-To: mailing list general@hadoop.apache.org Received: (qmail 54003 invoked by uid 99); 5 May 2011 00:22:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 May 2011 00:22:34 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of eli@cloudera.com designates 209.85.215.48 as permitted sender) Received: from [209.85.215.48] (HELO mail-ew0-f48.google.com) (209.85.215.48) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 May 2011 00:22:28 +0000 Received: by ewy22 with SMTP id 22so745624ewy.35 for ; Wed, 04 May 2011 17:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.17.100 with SMTP id i76mr829954eei.67.1304554928003; Wed, 04 May 2011 17:22:08 -0700 (PDT) Received: by 10.14.37.13 with HTTP; Wed, 4 May 2011 17:22:07 -0700 (PDT) In-Reply-To: References: <321761.51699.qm@web65903.mail.ac4.yahoo.com> Date: Wed, 4 May 2011 17:22:07 -0700 Message-ID: Subject: Re: [VOTE] Release candidate 0.20.203.0-rc1 From: Eli Collins To: general@hadoop.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Good suggestion, it would be helpful to hash out the issues around compatibility, feature branches, version numbers, how to contribute at Apache before putting up new votes that would be helpful, ie the vote would go much smoother if all the issues with the previous vote were addressed before starting a new one. Thanks, Eli On Wed, May 4, 2011 at 5:05 PM, Eric Baldeschwieler wrote: > Hi folks, > > Let's stay focused. Let's take the other threads onto other threads. This= is a vote. > > To the extent naming is a problem, let's take that to a thread and find a= n acceptable proposal. > > To the extent folks want to collaborate on certifying the release for tot= al lack of regression or collaborate on the cleanest possible merge, I thin= k all interested parties should take these topics to another thread and div= ide up the work. > > If you've voted, you don't need to comment further on this thread, no mat= ter what company you work for! > > Thanks, > > --- > E14 - typing on glass > > On May 4, 2011, at 4:46 PM, "Todd Lipcon" wrote: > >> On Wed, May 4, 2011 at 4:11 PM, Arun C Murthy wrote: >> >>> On May 4, 2011, at 4:09 PM, Tsz Wo (Nicholas), Sze wrote: >>> >>> The list seems highly inaccurate. =A0Checked the first few N/A items. = =A0All >>>> are >>>> false positives. >>>> >>>> >>> Also, =A0can you please provide a list on features which are not relate= d to >>> gridmix benchmarks or herriot tests? >>> >> >> Here are a few I quickly pulled up: >> MAPREDUCE-2316 (docs for improved capacity scheduler) >> MAPREDUCE-2355 (adds new config for heartbeat dampening in MR) >> >> " =A0 BZ-4182948. Add statistics logging to Fred for better visibility i= nto >> startup time costs. (Matt Foley)" >> - I believe I saw a note from Matt on the JIRA yesterday about this feat= ure, >> where he decided that the version done in 203 wasn't a good approach, an= d >> it's done differently in trunk (not sure if done yet). >> >> MAPREDUCE-2364 (important bug fix for localization) >> - in fact most of localization is different in this branch compared to t= runk >> due to inclusion of MAPREDUCE-2378, the trunk version of which is still = on >> the "yahoo-merge" branch,. >> >> "New cunters for FileInput/OutputFormat. New Counter >> =A0 =A0 =A0 =A0MAP_OUTPUT_MATERIALZIED_BYTES. Related bugs: 4241034, 341= 8543, >> 4217546" >> - not sure which JIRA this is, I think I've seen a JIRA for trunk, but n= ot >> committed. >> >> - MAPREDUCE-1904, committed without JIRA as: >> " =A0 =A0 =A0 =A0. Reducing new Path(), RawFileStatus() creation overhea= d in >> LocalDirAllocator" >> not in trunk >> >> + =A0 =A0BZ4101537 . =A0When a queue is built without any access rights = we explain >> the >> + =A0 =A0problem. =A0(dking, rvw ramach) =A0[attachment of 2010-11-24] >> seems to be on trunk as MR-2411, but not committed, best I can tell, des= pite >> the JIRA there being resolved (based on looking at QueueManager in trunk= ) >> >> " =A0 =A0 =A0 =A0. Remove unnecessary reference to user configuration fr= om >> TaskDistributedCacheManager causing memory leaks" >> Not in trunk, not sure which JIRA it might be.. probably part of 2178. >> >> Major new feature: MAPREDUCE-323 - very large rework of how job history >> files are managed >> Major change: MAPREDUCE-1100/MAPREDUCE-1176: unresolved on trunk, though >> probably will be attacked by different JIRAs >> Major new ops-visible feature: "metrics2" system >> Major new ops-visible feature: MAPREDUCE-291 job history can be viewed f= rom >> a separate server >> Major new set of user-visible configurations: MAPREDUCE-1943 and friends >> which implement new limits in MapReduce (eg MAPREDUCE-1872 as well) >> >> I have code to work on, so I won't keep going, but this is from looking = at >> the last couple months of 203. >> >> -Todd >> -- >> Todd Lipcon >> Software Engineer, Cloudera >