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 1D620106AE for ; Wed, 13 Nov 2013 18:13:05 +0000 (UTC) Received: (qmail 6326 invoked by uid 500); 13 Nov 2013 18:12:11 -0000 Delivered-To: apmail-hadoop-mapreduce-dev-archive@hadoop.apache.org Received: (qmail 4790 invoked by uid 500); 13 Nov 2013 18:11:46 -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 4770 invoked by uid 99); 13 Nov 2013 18:11:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Nov 2013 18:11:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_REMOTE_IMAGE X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of acm@hortonworks.com designates 209.85.223.169 as permitted sender) Received: from [209.85.223.169] (HELO mail-ie0-f169.google.com) (209.85.223.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Nov 2013 18:11:37 +0000 Received: by mail-ie0-f169.google.com with SMTP id tp5so1101228ieb.0 for ; Wed, 13 Nov 2013 10:11:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:content-type; bh=YDFsjvL9HQgSoccWzQvT7gN5fl8B4tdd96HZo4lWA10=; b=jtoADSvTyJAkr0yjVVP6i8LZLty8TTBPp1Mda3jZhs8zY7wdFUtxlwg6xziS+C790m XFkdQ1zCwBSIzUooxTt6lYyZTTOSea8uzSMCKXWaCunUSIfjgol5LXvtxrqmY3FaBPKk w20T9jvsmmlob1l8i+HooJUBxlMDNNYp7NwhVVC9NV8mc0vsXU2tyWVFnEH8DOiBWg5c uul9r2D8Jv5c3mHO2unKgJ/TOR1Da8awz3g6x1JO9OZEnCoWJPYGeKDigDIlGk8pFRU+ RoR5hKKnnVvLyA8ZuIkHjKCjAtAFqBt02ZKG96uF8qNnclgeNhBqcDfMnezwUT6rte0R 5mkQ== X-Gm-Message-State: ALoCoQnrJlq9bn+ynfyIzq+jiaaEU2Hv4LV0CNYXk4RlYHavbFnknCmPCusWGr3ybcICjqvPMXqdc9iC2aR8qja9gtL0WcTR0D2d879TP24glHkgV3bEcio= X-Received: by 10.50.154.101 with SMTP id vn5mr19246226igb.35.1384366276082; Wed, 13 Nov 2013 10:11:16 -0800 (PST) Received: from [192.168.154.128] ([198.203.175.254]) by mx.google.com with ESMTPSA id p14sm31444806igr.7.2013.11.13.10.11.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 10:11:15 -0800 (PST) From: Arun C Murthy Message-Id: <8AA38AE4-67A9-4E51-A7FE-E52CA4771B02@hortonworks.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Next releases Date: Wed, 13 Nov 2013 12:10:08 -0600 References:

To: hdfs-dev@hadoop.apache.org, "common-dev@hadoop.apache.org" , "mapreduce-dev@hadoop.apache.org" , "yarn-dev@hadoop.apache.org" In-Reply-To: X-Mailer: Apple Mail (2.1510) Content-Type: multipart/alternative; boundary="Apple-Mail=_2BA1AE19-3270-4B7B-94F3-5DF806EE70A1" X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_2BA1AE19-3270-4B7B-94F3-5DF806EE70A1 Content-Type: text/plain; charset=ISO-8859-1 On Nov 12, 2013, at 1:54 PM, Todd Lipcon wrote: > On Mon, Nov 11, 2013 at 2:57 PM, Colin McCabe wrote: > >> 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 *critical*, similarly in HDFS a cursory glance showed up some *enhancements*/*improvements* in CHANGES.txt which aren't necessary for a patch release, plus things like: HADOOP-9623 Update jets3t dependency to 0.9.0 Having said that, the HDFS devs know their code the best. > I agree with Colin. If we've been backporting things into a patch release > (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. Here is a straw man proposal: ---- A patch (third version) release should only include *blocker* bugs which are critical from an operational, security or data-integrity issues. 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 point in time. ---- Sandy did bring up a related point about timing of releases and the urge for everyone to cram features/fixes into a dot release. 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. Thoughts? thanks, Arun -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. --Apple-Mail=_2BA1AE19-3270-4B7B-94F3-5DF806EE70A1--