Return-Path: X-Original-To: apmail-hadoop-common-dev-archive@www.apache.org Delivered-To: apmail-hadoop-common-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DF7BCF8CC for ; Fri, 3 May 2013 08:07:33 +0000 (UTC) Received: (qmail 61873 invoked by uid 500); 3 May 2013 08:07:30 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 60373 invoked by uid 500); 3 May 2013 08:07:23 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 60306 invoked by uid 99); 3 May 2013 08:07:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 May 2013 08:07:21 +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 shv.hadoop@gmail.com designates 209.85.217.175 as permitted sender) Received: from [209.85.217.175] (HELO mail-lb0-f175.google.com) (209.85.217.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 May 2013 08:07:10 +0000 Received: by mail-lb0-f175.google.com with SMTP id w20so1296741lbh.20 for ; Fri, 03 May 2013 01:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SplSyjKE38nn+OtQxLXX7yd4OTYo0G23rfGeIPmqSvQ=; b=xeX/pDHAg3hx1+i135cs/SBkK9xJDsML7uCEKRr4jfAmNs/LalfOWzbuGSljbYfqn2 +fxJfHGgFwj2K2WpoZ0DwmRA5cF4edr81vdInQ91tnGaRNnzY+siZ8C2I2PvMUfY9xTh PGjphk2pTEYo1VGpW9LIXbQUiXK9FWxFYkB0yXgqU8VwGVmrMW+yIiT2Rsc8HZBx8NOo xjIwt0BkwGI6X9FopogufMqkbjt4HQfkly4D0Il3YNdOqefhsEptfAZ2gVh2fLYWjGgq Ap9v/RfBmy/MC8TpjxD2hIYzLOht6DnjVoapK0B6vrMcyo9D8P3uZfvPrRb0WJOmIzXk ba7g== MIME-Version: 1.0 X-Received: by 10.112.161.97 with SMTP id xr1mr3998259lbb.15.1367568408282; Fri, 03 May 2013 01:06:48 -0700 (PDT) Received: by 10.152.162.37 with HTTP; Fri, 3 May 2013 01:06:48 -0700 (PDT) In-Reply-To: References: <9408D111-C1D3-448C-A2E3-266A8CF4E176@hortonworks.com> <1BF4440E-7429-41C6-8020-EECFA2989329@hortonworks.com> Date: Fri, 3 May 2013 01:06:48 -0700 Message-ID: Subject: Re: Heads up - 2.0.5-beta From: Konstantin Shvachko To: "hdfs-dev@hadoop.apache.org" Cc: "common-dev@hadoop.apache.org" , "mapreduce-dev@hadoop.apache.org" , "yarn-dev@hadoop.apache.org" Content-Type: multipart/alternative; boundary=001a11c33af02e8b2504dbcbd5ae X-Virus-Checked: Checked by ClamAV on apache.org --001a11c33af02e8b2504dbcbd5ae Content-Type: text/plain; charset=ISO-8859-1 Hi Arun and Suresh, I am glad my choice of words attracted your attention. I consider this important for the project otherwise I wouldn't waste everybody's time. You tend reacting on a latest message taken out of context, which does not reveal full picture. I'll try here to summarize my proposal and motivation expressed earlier in these two threads: http://s.apache.org/fs http://s.apache.org/Streamlining I am advocating 1. to make 2.0.5 a release that will a) make any necessary changes so that Hadoop APIs could be fixed after that b) fix bugs: internal and those important for stabilizing downstream projects 2. Release 2.1.0 stable. I.e. both with stable APIs and stable code base. 3. Produce a series of feature releases. Potentially catching up with the state of trunk. 4. Release from trunk afterwards. The main motivation to minimize changes in 2.0.5 is to let Hadoop users and the downstream projects, that is the Hadoop community, to start adapting to the new APIs asap. This will provide certainty that people can build their products on top of 2.0.5 APIs with minimal risk the next release will break them. Thus Bobby in http://goo.gl/jm5am is saying that the meaning of beta for him is locked down APIs for wire and binary compatibility. For Hadoop Yahoo using 2.x is an opportunity to have it tested at very large scale, which in turn will bring other users on board. I agree with Arun that we are not disagreeing on much. Just on the order of execution: what goes first stability or features. I am not challenging any features, the implementations, or the developers. But putting all changes together is destructive for the stability of the release. Adding a 500 KB patch invalidates prio testing solely because it is a big change that needs testing not only by itself but with upstream applications. With 2.0.3 , 2.0.4 tested thoroughly and widely in many organizations and several distributions it seems like a perfect base for the stable release. We could be just two steps away from it. I tried to explained as good as I could what I suggest, why, and why now. I am not here to police, claim, mandate, enforce edicts, be a gatekeeper, narrow view, tie up knots ... (did I miss any). If we disagree let's do it by the rules we created for ourselves and move on. Life will self-adjust and the entropy will keep increasing no matter what. Thanks, --Konstantin --001a11c33af02e8b2504dbcbd5ae--