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 E63F9994E for ; Tue, 21 May 2013 23:03:07 +0000 (UTC) Received: (qmail 6307 invoked by uid 500); 21 May 2013 23:03:06 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 6077 invoked by uid 500); 21 May 2013 23:03:06 -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 6064 invoked by uid 99); 21 May 2013 23:03:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 23:03:06 +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 (nike.apache.org: domain of eli@cloudera.com designates 209.85.216.182 as permitted sender) Received: from [209.85.216.182] (HELO mail-qc0-f182.google.com) (209.85.216.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 23:02:59 +0000 Received: by mail-qc0-f182.google.com with SMTP id n1so717359qcw.13 for ; Tue, 21 May 2013 16:02:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=cxDwQDsjpEYwoUJUW5cdfSGKQSo4PKhp8GWsyK6Y598=; b=javMGZCTn+YH1EtNWmYVX/j/a4mbwxkOQ8PZoIBkWkHFy/eVh3mTCZpbg9ncbm707T mHqnaMpwNzzlhZ1wACVjZamDDBMBnLT4NnrdI3TKgGxnMlIJQWDl/RXhCRr9U7pdXd+Q wY6fpjipkS70ajmHqrgnCbxk7YpdY5SpvvBmiRUoSzjpd6JrT+Mk9taMLeWZlA3T2hhj rYsUTMwh9DaQaQ4ME0TdGS3ynLDDBB4MzkP9vhvYwMqx4Ib8iWDv+nz713tG3h2GtR9z 6zjA+QoebgVNQWKHV2kgbfUhE79ExIDoIuzCKLEM9wS0eeLKsqo6ntWWs6clVTQu8WQ2 wlsw== MIME-Version: 1.0 X-Received: by 10.49.38.169 with SMTP id h9mr4883201qek.54.1369177358731; Tue, 21 May 2013 16:02:38 -0700 (PDT) Received: by 10.229.170.15 with HTTP; Tue, 21 May 2013 16:02:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 May 2013 16:02:38 -0700 Message-ID: Subject: Re: [PROPOSAL] change in bylaws to remove Release Plan vote From: Eli Collins To: "common-dev@hadoop.apache.org" , mattf@apache.org Content-Type: multipart/alternative; boundary=047d7bdc12201a2c4704dd42727f X-Gm-Message-State: ALoCoQmKdaJmYplE5z8J08XUNmGsO/Np/Pzw9/2gjFq4lytCUCAIjVNulHV3mUfPEk0P9EdLFJ3B X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc12201a2c4704dd42727f Content-Type: text/plain; charset=ISO-8859-1 +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote: > Hi all, > This has been a side topic in several email threads recently. Currently we > have an ambiguity. We have a tradition in the dev community that any > committer can create a branch, and propose release candidates from it. Yet > the Hadoop bylaws say that releases have to be planned in advance, the plan > needs to be voted on, and presumably can be denied. > > Apache policies (primarily here > and here , with > non-normative commentary > here< > http://incubator.apache.org/guides/releasemanagement.html#best-practice>) > are very clear on how Releases have to be approved, and our bylaws are > consistent with those policies. But Apache policies don't say anything > I've found about Release Plans, nor about voting on Release Plans. > > I propose the following change, to remove Release Plan votes, and give a > simple definition of Release Manager role. I'm opening discussion with > this proposal, and will put it to a vote if we seem to be getting > consensus. Here's the changes I suggest in the > Bylaws > document: > > === > > 1. In the "Decision Making" : "Actions" section of the Bylaws, the > following text is removed: > > ** Release Plan* > > Defines the timetable and actions for a release. The plan also nominates a > Release Manager. > > Lazy majority of active committers > > > 2. In the "Roles and Responsibilities" section of the Bylaws, an additional > role is defined: > > ** Release Manager* > > A Release Manager (RM) is a committer who volunteers to produce a Release > Candidate according to > HowToRelease. > The RM shall publish a Release Plan on the *common-dev@* list stating the > branch from which they intend to make a Release Candidate, at least one > week before they do so. The RM is responsible for building consensus around > the content of the Release Candidate, in order to achieve a successful > Product Release vote. > > === > > Please share your views. > Best regards, > --Matt (long-time release manager) > --047d7bdc12201a2c4704dd42727f--