Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=IfBqpNOzqXP/k7FPKJc6lzJp+ZwPdMSE+FQhfAHF3E3g6mbBkd0XEeTYU4YBXAbibThsTGkalmbWnPJCrBSE8obLopVqBvnGJqS7XXMZZkZ0K98XagfmtT7BpsbRjQUDWCpRbaFtaUHl36fVpxFJ0aMqZQGUJv4oJsfpm86tkPk=;
References: 
 <CADcMMgHpF26xTcKbaNNFttYXk-PpeuT4wYzPiwwTyG8F3xgZWw@mail.gmail.com>
 <CADY20s47SPL9cZmkSV3GBWYEn6JW0Wfc_xEwubkmh6uPzDLVBA@mail.gmail.com>
Message-ID: <1347682557.8647.YahooMailNeo@web121706.mail.ne1.yahoo.com>
Date: Fri, 14 Sep 2012 21:15:57 -0700 (PDT)
From: lars hofhansl <lhofhansl@yahoo.com>
Reply-To: lars hofhansl <lhofhansl@yahoo.com>
Subject: Re: DISCUSSION: Component Lieutenants?
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CADY20s47SPL9cZmkSV3GBWYEn6JW0Wfc_xEwubkmh6uPzDLVBA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I like that idea.=0A=0AShould all PMC members or committers be at top level=
 of the source tree? Or will that just take us back to the status-quo?=0A=
=0A=0AI certainly like that a typical patch then will involve multiple revi=
ewer, and it will be more defined who should look at what patch.=0A=0A-- La=
rs=0A=0A=0A----- Original Message -----=0AFrom: Todd Lipcon <todd@cloudera.=
com>=0ATo: dev@hbase.apache.org=0ACc: =0ASent: Friday, September 14, 2012 1=
:15 PM=0ASubject: Re: DISCUSSION: Component Lieutenants?=0A=0AI like the id=
ea of lieutenants, but another option would be a=0A"multi-lieutenant" model=
.=0A=0AThe model used at google is that each directory has a file called=0A=
"OWNERS" which lists several usernames, one per line.=0A=0AFor any given pa=
tch, you are expected to get a review such that, for=0Aeach modified file, =
one of the OWNERS listed in that directory (or any=0Aparent thereof) has +1=
ed.=0A=0ASo, for example, imagine that hbase/OWNERS has only Stack, and=0Ah=
base/foo/component1/OWNERS has "jxiang,larsh". If I make a patch=0Awhich to=
uches something in foo/component1/bar/, I'd need a review from=0Aat least o=
ne of Jimmy, Lars, or Stack.=0A=0AThe assumption is that you try to get rev=
iew from the most specific=0Aowner, but if those people are MIA, you get re=
view from someone higher=0Aup the stack. The multi-person-per-dir model als=
o ensures that, if=0Asomeone's on vacation or otherwise busy, we don't get =
blocked. And it=0Aformalizes in the actual source tree who you should proba=
bly email if=0Ayou have questions about an area.=0A=0AIt also means that wi=
de-ranging patches that touch multiple components=0Aneed a lot of reviewers=
 (or someone higher up the chain of command who=0Ahas "permission" on the w=
hole tree). So if I had a mondo patch that=0Atouched the region server, the=
 master, and the IPC layer, I'd probably=0Aneed at least three separate peo=
ple to sign off.=0A=0AWhatever we do, rather than making it a strict policy=
, let's start out=0Awith a soft touch. Perhaps declare the component mainta=
iners and try=0Ato pick reviewers based on the criteria. But if people are =
busy and=0Awork needs to get done, we don't need to be anal about it :)=0A=
=0A-Todd=0A=0AOn Fri, Sep 14, 2012 at 12:17 PM, Stack <stack@duboce.net> wr=
ote:=0A> At the contributor's pow wow a few days ago [1], during a discussi=
on=0A> about whether or not commits should have more friction applied -- i.=
e.=0A> have more review before they go in -- it was thought that we might=
=0A> benefit if we had "lieutenants" over-seeing individual HBase=0A> compo=
nents.=A0 A lieutenant would be someone who has an interest and an=0A> unde=
rstanding of how a particular component works (or should work).=A0 A=0A> li=
eutenant does not need to be a committer.=A0 Before committing a patch=0A> =
that touched on a particular component, the patch would have to have=0A> be=
en +1'd by the component lieutenant before it could go in (or if the=0A> li=
eutenant is MIA, it was suggested by the Mighty Jon Hsieh that two=0A> +1s =
by other contributors/committers would do instead; this latter=0A> rule wou=
ld probably also apply when a patch spanned components).=0A>=0A> We already=
 have a few folks signed up, knowingly or otherwise, as=0A> component owner=
s [1].=0A>=0A> What do folks think?=0A>=0A> Should we go ahead w/ this proj=
ect?=A0 If so, any volunteers (I signed=0A> up a few of the obvious compone=
nt leads)?=A0 I can add you as component=0A> lieutenant into JIRA.=A0 We ca=
n add more components if you don't see=0A> your interest listed.=0A>=0A> St=
.Ack=0A>=0A> 1. http://www.meetup.com/hbaseusergroup/events/80621872/=0A=0A=
=0A=0A-- =0ATodd Lipcon=0ASoftware Engineer, Cloudera=0A