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 91D78D2C5 for ; Tue, 21 May 2013 21:14:47 +0000 (UTC) Received: (qmail 8233 invoked by uid 500); 21 May 2013 21:14:43 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 7977 invoked by uid 500); 21 May 2013 21:14:43 -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 7759 invoked by uid 99); 21 May 2013 21:14:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 21:14:43 +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 mfoley@hortonworks.com designates 209.85.217.177 as permitted sender) Received: from [209.85.217.177] (HELO mail-lb0-f177.google.com) (209.85.217.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 21:14:38 +0000 Received: by mail-lb0-f177.google.com with SMTP id o10so1334561lbi.36 for ; Tue, 21 May 2013 14:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=c0UN5kqksZcjSQ4E+vu0HgwMNlUUVoqkaDfrZ5MH9FE=; b=D7N9kq5BpRWmZ7u5z3//rjtBN75hVq41/xdshpjBmyPkk5fieBrZAinJATIQS+0jPt IKgru2y7tW97qIef+umWFVifiNSxyrU4i7sFOBI7QZyWVLLWopT0xRlx7JM/G4qjeDo9 XDN6Rly52zdDmhvMTlOnri1Pli1p6iuxCO4RC9+N70LGuaaevXsP2aYLE2fCbzaZ60uR YDDwD8ZhaNqByCfwMUzgWpE+Hn+mDih6INg/em3TT8wLUupc5F2IWqZ7gsbRmvhYoKXb 1Aw55zc0rmcj+n/MEpb7k88Kpvzz4hnudu4P5aXZTO4xlQ6h9PKIaqYzwGfH3mw+MQlM NSWA== X-Received: by 10.112.155.132 with SMTP id vw4mr2503198lbb.87.1369170857051; Tue, 21 May 2013 14:14:17 -0700 (PDT) MIME-Version: 1.0 Reply-To: mattf@apache.org Sender: mfoley@hortonworks.com Received: by 10.112.135.135 with HTTP; Tue, 21 May 2013 14:13:47 -0700 (PDT) In-Reply-To: References: <48A037BF-5EE8-44EA-BE27-0BBB46DA0B5B@hortonworks.com> From: Matt Foley Date: Tue, 21 May 2013 14:13:47 -0700 X-Google-Sender-Auth: Mw4rIXwwxC-jiNDVszZtmxiS2sc Message-ID: Subject: Re: [VOTE] - Release 2.0.5-beta To: "common-dev@hadoop.apache.org" Cc: "general@hadoop.apache.org" Content-Type: multipart/alternative; boundary=089e011770c7924d3704dd40ee22 X-Gm-Message-State: ALoCoQnPrO/yCurvMGkYx4gS44HbKPikVd3kWQHhJ1VYh65wYtlJ2U+mUlrY83DTFwLBSJrhPhtk X-Virus-Checked: Checked by ClamAV on apache.org --089e011770c7924d3704dd40ee22 Content-Type: text/plain; charset=ISO-8859-1 I've now started a separate discussion thread in common-dev@, titled "[PROPOSAL] change in bylaws to remove Release Plan vote". If it achieves consensus, I'll put it to a vote to so change the bylaws. Best, --Matt On Sat, May 18, 2013 at 4:22 PM, Chris Douglas wrote: > The "release plan" vote is not binding in any way. Nobody "lost" a > vote, or risks having an outcome reversed, because there are no > consequences to these exercises. > > Konstantin, I've been trying to tell you for more than a week that you > can go forward without anyone's blessing or consent. There are no > precedents, because the "release plan" vote has been a formality until > now, and I don't know of any other projects that even bother with it. > Most of our committers and PMC members didn't even know who was > eligible to vote on it, because we usually ignore it. What *does* > matter is the majority vote of the PMC on the release artifact. While > we under-defined what the release plan means, we have zero ambiguity > on when a release artifact becomes real. > > In the discussion, you were offered a minor release series, help > selecting patches from branch-2, and every administrative barrier was > removed from your path. Instead of taking this and running with it, > you continued to press for... I don't know what. Please decide how > you're going to move a development branch- any of them- forward and > start working on it. There is nothing to "win" in these threads. > > This has exposed a bug in our bylaws, which we can fix. > > Right now, these "votes" are confusing everybody and stalling the > project. I don't care who comes up with 2.0.5-beta, whether it's part > of 2.1, or if we create 3.0. Any committer who wants to offer an > candidate needs to demonstrate that they have a non-trivial, > non-sectarian proportion of the community behind it by (1) creating > the artifact (2) passing a PMC vote to make that artifact a release. > It's that simple. > > With respect to the board: they are not parents, and we are not > children. Neither are they interested or equipped to tell us how to > partition releases of Hadoop. This is routine development, we are > failing at it, but we will recover by eliminating this pointless > ritual and getting back to producing software. -C > > On Fri, May 17, 2013 at 1:10 PM, Konstantin Shvachko > wrote: > > BCC: general@ > > > > Since we recognize now that this is a vote to overrule previous decision, > > I am referring to Vinod's note on general > > *http://s.apache.org/h7x* > > should this be brought to the attention of the Board? > > > > I don't remember any precedents of this kind in Hadoop history. > > But other projects may have had such experience. > > A clarification on categorizing this action and on voting practices > > from ASF may help. > > > > Thanks, > > --Konstantin > > > > > > > > On Wed, May 15, 2013 at 3:36 PM, Konstantin Shvachko > > wrote: > > > >> Arun, > >> > >> I am glad I at least convinced you to finally announce your release plan > >> and put it into vote. > >> Even though it is to overrule the vote that just completed, which you > were > >> against and lost, well - Twice. > >> > >> I am glad you removed the NFS feature from the list proposed earlier. > >> > >> I think this vote is late. The lazy consensus on that issue has been > just > >> reached. > >> I don't see the basis for the new vote, > >> and it is not clear what action you seek to approve. > >> > >> Thanks, > >> --Konstantin > >> > >> > >> > >> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy >wrote: > >> > >>> Folks, > >>> > >>> A considerable number of people have expressed confusion regarding the > >>> recent vote on 2.0.5, beta status etc. given lack of specifics, the > voting > >>> itself (validity of the vote itself, whose votes are binding) etc. > >>> > >>> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current > >>> stability of 3 features under debate etc.) have been lost in the > discussion > >>> in favor of non-technical (almost dramatic) nuances such as "seizing > the > >>> moment". There is now dangerous talk of tolerating incompatibility b/w > 2.0 > >>> and 2.1) - this is a red flag for me; particularly when there are just > 3 > >>> features being debated and active committers and contributors are > confident > >>> of and ready to stand by their work. All patches, I believe, are ready > to > >>> be merged in the the next few days per discussions on jira. This will, > >>> clearly, not delay the other API work which everyone agrees is > crucial. As > >>> a result, I feel no recourse but to restart a new vote - all attempts > at > >>> calm, reasoned, civil discussion based on technical arguments have > come to > >>> naught - I apologize for the thrash caused to everyone's attention. > >>> > >>> To get past all of this confusion, I'd like to present an alternate, > >>> specific proposal for consideration. > >>> > >>> I propose we continue the original plan and make a 2.0.5-beta release > by > >>> May end with the following content: > >>> # HDFS-347 > >>> # HDFS Snapshots > >>> # Windows support > >>> # Necessary & final API/protocol changes such as: > >>> * Final YARN API changes: YARN-386 > >>> * MR Binary Compatibility: MAPREDUCE-5108 > >>> * Final RPC cleanup: HADOOP-8990 > >>> > >>> People working on the above features have all expressed considerable > >>> comfort with them and are ready to stand-by to help expedite any > necessary > >>> bug-fixes etc. to get to stabilization quickly. I'm confident we can > get > >>> this release out by end of May. This sets stage for a hadoop-2.x GA > release > >>> right after with some more testing - this means I think I can quickly > turn > >>> around and make bug-fix releases as necessary right after 2.0.5-beta. > >>> > >>> I request that people consider helping out with this plan and sign up > to > >>> help push hadoop-2.x to stability as outlined above. I believe this > will > >>> help achieve our shared goals of quickly stabilizing hadoop-2 and help > >>> ensure we can support it for forseeable future in a compatible manner > for > >>> the benefit of our users and downstream projects. > >>> > >>> Please vote, the vote will run the normal 7 days. Obviously, I'm +1. > >>> > >>> thanks, > >>> Arun > >>> > >>> PS: To keep this discussion grounded in technical details I've moved > this > >>> to dev@ (bcc general@). > >>> > >>> > >> > --089e011770c7924d3704dd40ee22--