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 DA36DF9D4 for ; Fri, 10 May 2013 04:14:00 +0000 (UTC) Received: (qmail 25162 invoked by uid 500); 10 May 2013 04:13:59 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 24918 invoked by uid 500); 10 May 2013 04:13:58 -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 24897 invoked by uid 99); 10 May 2013 04:13:58 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 04:13:57 +0000 Received: from localhost (HELO mail-vc0-f170.google.com) (127.0.0.1) (smtp-auth username apurtell, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 04:13:57 +0000 Received: by mail-vc0-f170.google.com with SMTP id gf12so3357673vcb.15 for ; Thu, 09 May 2013 21:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=shCoi8Q05vaqPHxq2HEo0XAtYruIGq/R7Dx5OuFF/10=; b=gN2yklCNj3JJe8Ibbd5BfNVjeLgiMIebXQARwJyDFyMzU+XKTZE8jDLHTVuFqLbRga +wXRup5CQ/OYnEv6n58N4/2lsb95qtGVvVksOAKHjehGdZymnHMhFal7EBT9q7n+XEbU TKorQqZeqAKxzZ7FLXBLV0O8ZEGhSFJCOQoPJPUFTXMIro+WV9JX3WJ/yhRO96XxfSGb bf85K37LLJg3u1GFKGOGZzVkJLUCLoIhcyJthDF8H7at+fZzOFnw2VwN/A24iMoeV77C ncG6fus4m8544A9L9MLewJAnZY6cASphhtsbho/jYsVm58uhZxdGHhySH44huiLNbsDa AlTg== X-Received: by 10.58.220.129 with SMTP id pw1mr10014432vec.32.1368159236446; Thu, 09 May 2013 21:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.227.161 with HTTP; Thu, 9 May 2013 21:13:16 -0700 (PDT) In-Reply-To: References: From: Andrew Purtell Date: Fri, 10 May 2013 12:13:16 +0800 Message-ID: Subject: Re: [VOTE] Release plan for Hadoop 2.0.5 To: "general@hadoop.apache.org" Content-Type: multipart/alternative; boundary=047d7bd6a8ce48e73104dc556544 --047d7bd6a8ce48e73104dc556544 Content-Type: text/plain; charset=ISO-8859-1 Making 2.0.x stable is really important for adoption of it as the new production quality Hadoop. I think Hadoop should adopt the merge window concept. After a release, a new branch is opened for development. There is a window of time when changes can go in, then the window is closed, then the branch is stabilized, then the next major release is made off of the stabilized branch. Repeat. What constitutes a major release numbering transition could be from e.g. 2.x to 3.x, or from e.g. 2.0.x to 2.1.x. Either would work. If feature development misses a window, it waits for the next. That is completely fair and predictable. If the periodicity of open merge windows is also predictable that is even better. If Hadoop can consider the merge window now closed for 2.0.x, that would be great, it has been open for a very long time. +1 (nonbinding) after all of that, apologies for the verbiage but the stability of the Hadoop ecosystem's foundation is a very important topic. If I had a binding vote I would have voted +0 so as not to be presumptuous, since my vote is nonbinding please consider it user feedback. Every single project downstream is affected. We don't have a binding stake in the voting but please consider us in your deliberations. IMHO, a 2.1.0 branch and short merge window for getting HDFS snapshots out there should quickly follow, and then the necessary 3-6 months of scale testing. By all accounts talking with users it is the remaining compelling feature missing from Hadoop 2. On Fri, May 10, 2013 at 10:58 AM, lohit wrote: > +1 > Particularly making 2.0.X stable will help wider adoption sooner. > > > 2013/5/9 J. Rottinghuis > > > +1 (non-binding) to stabilize 2.0, and add new features only after a > stable > > release. > > I understand that what constitutes as "new feature" versus "stabilizing" > is > > subjective. > > > > Thanks, > > > > Joep > > > > On May 1, 2013, at 12:53 PM, Konstantin Shvachko wrote: > > > > > > > Please vote on the following plan for Hadoop release 2.0.5 > > > > - bug fixes encountered in current release 2.0.4-alpha > > > > - make all API changes to allow freezing them post 2.0.5 > > > > - no new features > > > > > > > > As discussed on @dev thread > > > > http://s.apache.org/fs > > > > this will allow to stabilize 2.0 branch in a short and predictable > > period > > > > of time. > > > > This enables a powerful option to have the release tested at Yahoo > > scale. > > > > The plan is to follow up with 2.1.0 - the stable release. > > > > New features can and should be added on top of the stable release > once > > it > > > > is out. > > > > > > > > Hadoop by-laws: > > > > http://hadoop.apache.org/bylaws.html > > > > > > > > "Release Plan > > > > Defines the timetable and actions for a release. The plan also > > nominates > > > a > > > > Release Manager. > > > > Lazy majority of active committers" > > > > > > > > assume nomination of a Release Manager with the plan. > > > > It would be really good if Arun continues if this plan is adopted. > > > > We can return to the RM topic if not. > > > > > > > > The vote will run for 7 days until next Wed, May 8th. > > > > > > > > Thanks, > > > > --Konstantin > > > > > > > > > > > > -- > Have a Nice Day! > Lohit > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) --047d7bd6a8ce48e73104dc556544--