Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
References: 
 <CALte62yVAO2UQn2hr=OGO+NN2cLAm23tKhiHxKr6xzEg_t7GBA@mail.gmail.com>
 <CADcMMgHoHv_q4iRVK7_fpeRJfp6B_QYzhLoCCm-NfVQ=kjp0_g@mail.gmail.com>
Message-ID: <1311876611.96664.YahooMailNeo@web65514.mail.ac4.yahoo.com>
Date: Thu, 28 Jul 2011 11:10:11 -0700 (PDT)
From: Andrew Purtell <apurtell@apache.org>
Reply-To: Andrew Purtell <apurtell@apache.org>
Subject: Re: HBase 0.92 branch
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CADcMMgHoHv_q4iRVK7_fpeRJfp6B_QYzhLoCCm-NfVQ=kjp0_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-75916762-1311876611=:96664"

--0-75916762-1311876611=:96664
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>=A0New issues outside the list have to collect 3 +1 from committers=A0befo=
re going in.=0A=A0=0A-1=A0=0A=0ADo we actually have bylaws?=0A=0AOur practi=
ce is RTC with one +1 other than patch creator being sufficient for commit,=
 and CTR for trivial changes. I'm -1 on changing this.=0A=0AHadoop core rec=
ently ran a vote to increase the threshold for RTC to three +1s for commits=
 that represent a branch merge. I support this for HBase. So if people thin=
k some big "new issue" needs additional review, then we make a feature bran=
ch for it and require three +1s for merge commit.=0A=0ABest regards,=0A=0A=
=0A=A0 =A0- Andy=0A=0AProblems worthy of attack prove their worth by hittin=
g back. - Piet Hein (via Tom White)=0A=0A=0A>______________________________=
__=0A>From: Stack <stack@duboce.net>=0A>To: dev@hbase.apache.org=0A>Sent: T=
hursday, July 28, 2011 10:04 AM=0A>Subject: Re: HBase 0.92 branch=0A>=0A>On=
 Thu, Jul 28, 2011 at 9:47 AM, Ted Yu <yuzhihong@gmail.com> wrote:=0A>> Sin=
ce build 2047, TRUNK build has been on a steady decline. I believe even=0A>=
> if this trend is reversed, it is hard to guarantee that TRUNK build would=
 be=0A>> healthy in the future.=0A>=0A>I think we can fix it.=0A>=0A>> Now =
that the issues on http://s.apache.org/x4 have come down to 18, I think=0A>=
> we should consider branching 0.92 soon (maybe after HFile v2 and HBASE-40=
27=0A>> go in and we fix the broken build).=0A>=0A>I suppose I'd like the i=
ssues to go to zero before we branched but I=0A>can go along w/ the above; =
if we held to my way of doing things we=0A>might never branch.=0A>=0A>=0A>>=
 After branching, we can focus on the following:=0A>> 1. every checkin to 0=
.92 branch shouldn't break its build. This requires the=0A>> committer to p=
erform at least one complete test suite run before checking=0A>> in.=0A>=0A=
>I'll set up a build of the branch soon as we branch.=A0 I've been=0A>respo=
nsible for build breakage of late.=A0 Will reform myself.=0A>=0A>> 2. patch=
es for issues on http://s.apache.org/x4 are allowed to go into 0.92=0A>> br=
anch. New issues outside the list have to collect 3 +1 from committers=0A>>=
 before going in.=0A>>=0A>=0A>I'd say 3+1s if its a 'big' change.=A0 The sm=
all stuff should just let go through.=0A>=0A>Good stuff,=0A>St.Ack=0A>=0A>=
=0A>
--0-75916762-1311876611=:96664--