Return-Path: 
 <general-return-4037-apmail-hadoop-general-archive=hadoop.apache.org@hadoop.apache.org>
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 A56FA6EF1
	for <apmail-hadoop-general-archive@minotaur.apache.org>;
 Tue, 12 Jul 2011 17:01:38 +0000 (UTC)
Received: (qmail 90665 invoked by uid 500); 12 Jul 2011 17:01:36 -0000
Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org
Received: (qmail 90485 invoked by uid 500); 12 Jul 2011 17:01:35 -0000
Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:general-help@hadoop.apache.org>
List-Unsubscribe: <mailto:general-unsubscribe@hadoop.apache.org>
List-Post: <mailto:general@hadoop.apache.org>
List-Id: <general.hadoop.apache.org>
Reply-To: general@hadoop.apache.org
Delivered-To: mailing list general@hadoop.apache.org
Received: (qmail 89887 invoked by uid 99); 12 Jul 2011 17:01:33 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2011 17:01:33 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of saint.ack@gmail.com designates
 209.85.216.48 as permitted sender)
Received: from [209.85.216.48] (HELO mail-qw0-f48.google.com) (209.85.216.48)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2011 17:01:25 +0000
Received: by qwj9 with SMTP id 9so3644299qwj.35
        for <general@hadoop.apache.org>; Tue, 12 Jul 2011 10:01:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=nw8DA7r5cpDSekUvKm2INOuqcpzajq/p+rHM1ayu62E=;
        b=OrL91d/qrM9Sb0Xvzks4/ESVDGMJOvnwD102ospEe5RvF2wd093Aim2Z+6o9fl1CYB
         JerkM6ceUA+Ql+S6pEtaf4aNrJ865tsDdnJVDWq8if3zWtdIpDU6u9XSrxGlrFQlkbE8
         8BqaaymVfFx8lBWG2GDKOqqf2mpJdXMq2Rksg=
MIME-Version: 1.0
Received: by 10.224.193.137 with SMTP id du9mr185758qab.115.1310490064585;
 Tue, 12 Jul 2011 10:01:04 -0700 (PDT)
Sender: saint.ack@gmail.com
Received: by 10.224.60.196 with HTTP; Tue, 12 Jul 2011 10:01:04 -0700 (PDT)
In-Reply-To: 
 <CAPn_vTunwd=yyM06=dHooLT-dv4Vq563xmuy-F70nDEidsfiqQ@mail.gmail.com>
References: 
 <CADiKvVvYhSTSBDokOqvapu-OYUrVEtOC+TCaqB2faQLisDWHbA@mail.gmail.com>
	<CAPn_vTunwd=yyM06=dHooLT-dv4Vq563xmuy-F70nDEidsfiqQ@mail.gmail.com>
Date: Tue, 12 Jul 2011 10:01:04 -0700
X-Google-Sender-Auth: Rm8tks27jd57FrgivgQKcTA1R-0
Message-ID: 
 <CADcMMgHPnV1=qQw+Ais_Lghrh_Ek0VJ79nWRimzuYu_z3TGUQw@mail.gmail.com>
Subject: Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge
From: Stack <stack@duboce.net>
To: general@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

+1

On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins <eli@cloudera.com> wrote:
> +1 =A0 Sounds good to me.
>
> Something like the following?
>
> Index: main/author/src/documentation/content/xdocs/bylaws.xml
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =A0 =A0 =A0 =A0 =A0 =A0 <p>Lazy consensus of active committers, but with =
a minimum of
> - =A0 =A0 =A0 =A0 =A0 =A0one +1. The code can be committed after the firs=
t +1.</p></li>
> + =A0 =A0 =A0 =A0 =A0 =A0one +1. The code can be committed after the firs=
t +1, unless
> + =A0 =A0 =A0 =A0 =A0 =A0the code change represents a merge from a branch=
, in which case
> + =A0 =A0 =A0 =A0 =A0 =A0three +1s are required.</p></li>
>
>
>
>
> On Mon, Jul 11, 2011 at 5:11 PM, Jakob Homan <jghoman@gmail.com> wrote:
>> As discussed in the recent thread on HDFS-1623 branching models, I'd
>> like to amend the bylaws to provide that branches should get a minimum
>> of three committer +1s before being merged to trunk.
>>
>> The rationale:
>> Feature branches are often created in order that developers can
>> iterate quickly without the review then commit requirements of trunk.
>> Branches' commit requirements are determined by the branch maintainer
>> and in this situation are often set up as commit-then-review. =A0As
>> such, there is no way to guarantee that the entire changeset offered
>> for trunk merge has had a second pair of eyes on it. =A0Therefore, it is
>> prudent to give that final merge heightened scrutiny, particularly
>> since these branches often extensively affect critical parts of the
>> system. =A0Requiring three binding +1s does not slow down the branch
>> development process, but does provide a better chance of catching bugs
>> before they make their way to trunk.
>>
>> Specifically, under the Actions subsection, this vote would add a new
>> bullet item:
>> * Branch merge: A feature branch that does not require the same
>> criteria for code to be committed to trunk will require three binding
>> +1s before being merged into trunk.
>>
>> The last bylaw change required lazy majority of PMC and ran for 7
>> days, which I believe would apply to this one as well. =A0That would
>> have this vote ending 5pm PST July 18.
>> -Jakob
>>
>