Return-Path: X-Original-To: apmail-hadoop-mapreduce-dev-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BDEB410FC2 for ; Wed, 20 Nov 2013 14:39:02 +0000 (UTC) Received: (qmail 77729 invoked by uid 500); 20 Nov 2013 14:38:44 -0000 Delivered-To: apmail-hadoop-mapreduce-dev-archive@hadoop.apache.org Received: (qmail 76518 invoked by uid 500); 20 Nov 2013 14:38:33 -0000 Mailing-List: contact mapreduce-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mapreduce-dev@hadoop.apache.org Delivered-To: mailing list mapreduce-dev@hadoop.apache.org Received: (qmail 76488 invoked by uid 99); 20 Nov 2013 14:38:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Nov 2013 14:38:31 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of acm@hortonworks.com designates 209.85.160.41 as permitted sender) Received: from [209.85.160.41] (HELO mail-pb0-f41.google.com) (209.85.160.41) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Nov 2013 14:38:27 +0000 Received: by mail-pb0-f41.google.com with SMTP id jt11so10115081pbb.28 for ; Wed, 20 Nov 2013 06:38:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:content-type; bh=wDaAviP/AA8zPHz68bg27vaHwDVtpqPBHMjSUDB0SiY=; b=Y1sYTF6xvoznTxVZT94Cx1jtTthSamCULEIbKgysY/AY7gJ3d/MSPBZeNi+KLjh6Yy VSjrri41Lc3n5qMEetu5JVHag2MlhWcS/MuuR3hVEjvP/EOURg+yLG0pfCuUKtlmtx82 ZK4baeOu9jBkInlkdLPzGAySIyZ5vF+p0cR+aAZEB513hV7W9weVgX9VxIwPS/plkXL1 0+07Z9/+K5Gz0nqDxGEdxCn1lTUb2FTEdZ7TqzPBI4wmHLP0qqAysOnDzqrE5bHvu223 jGi5C7na3i77Lv9lw1nZ0RyzMwVPXF+WKAc3q+OJkBMGt9N1gaZawhIDfGMSo6uoO11Z 9IkA== X-Gm-Message-State: ALoCoQkYrGqDUMQQOB+hOgoY/++iQPGAdaB8jcfkCvF2ZWTZRMVDPfl2t7dsxq2OMxCRUEjBLuYMf6i7ev6iq3Y6eRAOizBzLjg9l6izkf3FyUQqyq8Kd4s= X-Received: by 10.66.162.73 with SMTP id xy9mr1014785pab.172.1384958286634; Wed, 20 Nov 2013 06:38:06 -0800 (PST) Received: from [10.0.1.25] (c-98-234-189-94.hsd1.ca.comcast.net. [98.234.189.94]) by mx.google.com with ESMTPSA id ql10sm38319894pbc.44.2013.11.20.06.38.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 06:38:05 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Next releases From: Arun C Murthy In-Reply-To: <5283F543.1090008@yahoo-inc.com> Date: Wed, 20 Nov 2013 06:38:03 -0800 Cc: , , "common-dev@hadoop.apache.org" Message-Id: <0ACA31B4-4A4B-4980-A6AF-708D6FF1B183@hortonworks.com> References: <8AA38AE4-67A9-4E51-A7FE-E52CA4771B02@hortonworks.com> <5283F543.1090008@yahoo-inc.com> To: mapreduce-dev@hadoop.apache.org X-Mailer: Apple Mail (2.1510) Content-Type: multipart/alternative; boundary="Apple-Mail=_E8777E0D-E90F-4FFB-AF11-66BBA8718053" X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_E8777E0D-E90F-4FFB-AF11-66BBA8718053 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Jason, I'm glad to see we are converging. I'll update the Roadmap wiki with detai= ls about major/minor/patch releases. Here is a straight-forward approach for now: I'll just roll contents of br= anch-2.2 as a 2.3-rc0 candidate right-away. This way we don't have to get e= mbroiled in details of individual patches (there are too many). Next up, I'= ll roll 2.4 in December. Thoughts? thanks, Arun On Nov 13, 2013, at 1:55 PM, Jason Lowe wrote: > I think a lot of confusion comes from the fact that the 2.x line is start= ing to mature. Before this there wasn't such a big contention of what went= into patch vs. minor releases and often the lines were blurred between the= two. However now we have significant customers and products starting to u= se 2.x as a base, which means we need to start treating it like we treat 1.= x. That means getting serious about what we should put into a patch releas= e vs. what we postpone to a minor release. >=20 > Here's my $0.02 on recent proposals: >=20 > +1 to releasing more often in general. A lot of the rush to put changes = into a patch release is because it can be a very long time between any kind= of release. If minor releases are more frequent then I hope there would b= e less of a need to rush something or hold up a release. >=20 > +1 to limiting checkins of patch releases to Blockers/Criticals. If nece= ssary committers check into trunk/branch-2 only and defer to the patch rele= ase manager for the patch release merge. Then there should be fewer surpri= ses for everyone what ended up in a patch release and less likely the patch= release becomes destabilized from the sheer amount of code churn. Maybe t= his won't be necessary if everyone understands that the patch release isn't= the only way to get a change out in timely manner. >=20 > As for 2.2.1, again I think it's expectations for what that release means= . If it's really just a patch release then there shouldn't be features in = it and tons of code churn, but I think many were treating it as the next ve= hicle to deliver changes in general. If we think 2.2.1 is just as good or = better than 2.2.0 then let's wrap it up and move to a more disciplined appr= oach for subsequent patch releases and more frequent minor releases. >=20 > Jason >=20 > On 11/13/2013 12:10 PM, Arun C Murthy wrote: >> On Nov 12, 2013, at 1:54 PM, Todd Lipcon wrote: >>=20 >>> On Mon, Nov 11, 2013 at 2:57 PM, Colin McCabe w= rote: >>>=20 >>>> To be honest, I'm not aware of anything in 2.2.1 that shouldn't be >>>> there. However, I have only been following the HDFS and common side >>>> of things so I may not have the full picture. Arun, can you give a >>>> specific example of something you'd like to "blow away"? >> There are bunch of issues in YARN/MapReduce which clearly aren't *critic= al*, similarly in HDFS a cursory glance showed up some *enhancements*/*impr= ovements* in CHANGES.txt which aren't necessary for a patch release, plus t= hings like: >>=20 >> HADOOP-9623=09 >> Update jets3t dependency to 0.9.0 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =20 >> Having said that, the HDFS devs know their code the best. >>=20 >>> I agree with Colin. If we've been backporting things into a patch relea= se >>> (third version component) which don't belong, we should explicitly call= out >>> those patches, so we can learn from our mistakes and have a discussion >>> about what belongs. >> Good point. >>=20 >> Here is a straw man proposal: >>=20 >> ---- >> A patch (third version) release should only include *blocker* bugs which= are critical from an operational, security or data-integrity issues. >>=20 >> This way, we can ensure that a minor series release (2.2.x or 2.3.x or 2= .4.x) is always release-able, and more importantly, deploy-able at any poin= t in time. >>=20 >> ---- >>=20 >> Sandy did bring up a related point about timing of releases and the urge= for everyone to cram features/fixes into a dot release. >>=20 >> So, we could remedy that situation by doing a release every 4-6 weeks (2= .3, 2.4 etc.) and keep the patch releases limited to blocker bugs. >>=20 >> Thoughts? >>=20 >> thanks, >> Arun >>=20 >>=20 >>=20 >>=20 >>=20 >=20 -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ --=20 CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to= =20 which it is addressed and may contain information that is confidential,=20 privileged and exempt from disclosure under applicable law. If the reader= =20 of this message is not the intended recipient, you are hereby notified that= =20 any printing, copying, dissemination, distribution, disclosure or=20 forwarding of this communication is strictly prohibited. If you have=20 received this communication in error, please contact the sender immediately= =20 and delete it from your system. Thank You. --Apple-Mail=_E8777E0D-E90F-4FFB-AF11-66BBA8718053--