Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.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;
  b=fzPifRwQR4Gy/Z8BL+ixPRRUW2C1ZvIoAvFV/iRQ+me09FoFdEds2wVTmfDd8s8ndr1/tGGw+3fqUJZMYAr2IXBeUphNprbFgP2FkbuMrZ+2uVmOV6lRw0WQk+e3KG2pQ5jW0d63wxVxmurn/kMVMBsWRHZHNiOI7RphUTXABeE=;
References: 
 <CADcMMgHpF26xTcKbaNNFttYXk-PpeuT4wYzPiwwTyG8F3xgZWw@mail.gmail.com>
 <CADY20s47SPL9cZmkSV3GBWYEn6JW0Wfc_xEwubkmh6uPzDLVBA@mail.gmail.com>
 <1347682557.8647.YahooMailNeo@web121706.mail.ne1.yahoo.com>
 <CADY20s7SjzD7-ghv1b3UnW_f+OB+3BAFM1gA_-TxM6PN78tGAA@mail.gmail.com>
 <BB4AE1E9-E7B1-417B-B988-9946420AD3D5@gmail.com>
Message-ID: <1347923626.29874.YahooMailNeo@web121702.mail.ne1.yahoo.com>
Date: Mon, 17 Sep 2012 16:13:46 -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: <BB4AE1E9-E7B1-417B-B988-9946420AD3D5@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="896913286-1349971497-1347923626=:29874"

--896913286-1349971497-1347923626=:29874
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Maybe just make it an informal list of (self declared :) ) "specialists". F=
or example if I see changes in the Assignment code that I do not understand=
 I usually defer to Ram. If there's some HFile stuff, I defer to Mikhail...=
=0A=0AIf we had a list of specialists, it would be easier to defer to them,=
 or to pull them into a review. I think that would be better than strict gu=
idelines.=0A=0A=0AI'd volunteer for: Transactions/MVCC, Scanners/Scanning/Q=
ueryMatcher, Client, Deletion, Performance.=0A=0A=0A=0A____________________=
____________=0A From: Andrew Purtell <andrew.purtell@gmail.com>=0ATo: "dev@=
hbase.apache.org" <dev@hbase.apache.org> =0ACc: "dev@hbase.apache.org" <dev=
@hbase.apache.org>; lars hofhansl <lhofhansl@yahoo.com> =0ASent: Monday, Se=
ptember 17, 2012 3:08 PM=0ASubject: Re: DISCUSSION: Component Lieutenants?=
=0A =0AWhy doesn't every committer or contributor with interest volunteer? =
Some overlap there would be good. Beyond that we can list the remaining are=
as without good coverage and nominate for them?=0A=0AI volunteer for Coproc=
essors, REST, security, filters, and client. =0A=0AOn Sep 17, 2012, at 2:12=
 PM, Todd Lipcon <todd@cloudera.com> wrote:=0A=0A> On Fri, Sep 14, 2012 at =
9:15 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:=0A>> I like that idea.=
=0A>> =0A>> Should all PMC members or committers be at top level of the sou=
rce tree? Or will that just take us back to the status-quo?=0A>> =0A> =0A> =
I feel like that would take us back to the status quo.=0A> =0A> The downsid=
e of this proposal is that we should probably have some=0A> well-principled=
 way of determining who gets "ownership" (whether=0A> co-ownership or alone=
) of each part of the heirarchy. I fear it could=0A> become political or di=
scourage people from contributing or reviewing=0A> code outside their area =
of expertise. So, if people have good ideas on=0A> how to go about doing th=
is, please shout them out!=0A> =0A>> =0A>> I certainly like that a typical =
patch then will involve multiple reviewer, and it will be more defined who =
should look at what patch.=0A>> =0A>> -- Lars=0A>> =0A>> =0A>> ----- Origin=
al Message -----=0A>> From: Todd Lipcon <todd@cloudera.com>=0A>> To: dev@hb=
ase.apache.org=0A>> Cc:=0A>> Sent: Friday, September 14, 2012 1:15 PM=0A>> =
Subject: Re: DISCUSSION: Component Lieutenants?=0A>> =0A>> I like the idea =
of lieutenants, but another option would be a=0A>> "multi-lieutenant" model=
.=0A>> =0A>> The model used at google is that each directory has a file cal=
led=0A>> "OWNERS" which lists several usernames, one per line.=0A>> =0A>> F=
or any given patch, you are expected to get a review such that, for=0A>> ea=
ch modified file, one of the OWNERS listed in that directory (or any=0A>> p=
arent thereof) has +1ed.=0A>> =0A>> So, for example, imagine that hbase/OWN=
ERS has only Stack, and=0A>> hbase/foo/component1/OWNERS has "jxiang,larsh"=
. If I make a patch=0A>> which touches something in foo/component1/bar/, I'=
d need a review from=0A>> at least one of Jimmy, Lars, or Stack.=0A>> =0A>>=
 The assumption is that you try to get review from the most specific=0A>> o=
wner, but if those people are MIA, you get review from someone higher=0A>> =
up the stack. The multi-person-per-dir model also ensures that, if=0A>> som=
eone's on vacation or otherwise busy, we don't get blocked. And it=0A>> for=
malizes in the actual source tree who you should probably email if=0A>> you=
 have questions about an area.=0A>> =0A>> It also means that wide-ranging p=
atches that touch multiple components=0A>> need a lot of reviewers (or some=
one higher up the chain of command who=0A>> has "permission" on the whole t=
ree). So if I had a mondo patch that=0A>> touched the region server, the ma=
ster, and the IPC layer, I'd probably=0A>> need at least three separate peo=
ple to sign off.=0A>> =0A>> Whatever we do, rather than making it a strict =
policy, let's start out=0A>> with a soft touch. Perhaps declare the compone=
nt maintainers and try=0A>> to pick reviewers based on the criteria. But if=
 people are busy and=0A>> work needs to get done, we don't need to be anal =
about it :)=0A>> =0A>> -Todd=0A>> =0A>> On Fri, Sep 14, 2012 at 12:17 PM, S=
tack <stack@duboce.net> wrote:=0A>>> At the contributor's pow wow a few day=
s ago [1], during a discussion=0A>>> about whether or not commits should ha=
ve 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-s=
eeing individual HBase=0A>>> components.=A0 A lieutenant would be someone w=
ho has an interest and an=0A>>> understanding of how a particular component=
 works (or should work).=A0 A=0A>>> lieutenant does not need to be a commit=
ter.=A0 Before committing a patch=0A>>> that touched on a particular compon=
ent, the patch would have to have=0A>>> been +1'd by the component lieutena=
nt before it could go in (or if the=0A>>> lieutenant is MIA, it was suggest=
ed by the Mighty Jon Hsieh that two=0A>>> +1s by other contributors/committ=
ers would do instead; this latter=0A>>> rule would probably also apply when=
 a patch spanned components).=0A>>> =0A>>> We already have a few folks sign=
ed up, knowingly or otherwise, as=0A>>> component owners [1].=0A>>> =0A>>> =
What do folks think?=0A>>> =0A>>> Should we go ahead w/ this project?=A0 If=
 so, any volunteers (I signed=0A>>> up a few of the obvious component leads=
)?=A0 I can add you as component=0A>>> lieutenant into JIRA.=A0 We can add =
more components if you don't see=0A>>> your interest listed.=0A>>> =0A>>> S=
t.Ack=0A>>> =0A>>> 1. http://www.meetup.com/hbaseusergroup/events/80621872/=
=0A>> =0A>> =0A>> =0A>> --=0A>> Todd Lipcon=0A>> Software Engineer, Clouder=
a=0A>> =0A> =0A> =0A> =0A> -- =0A> Todd Lipcon=0A> Software Engineer, Cloud=
era
--896913286-1349971497-1347923626=:29874--