hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: DISCUSSION: Component Lieutenants?
Date Tue, 18 Sep 2012 18:47:24 GMT
I'd add WAL/HLog, Mutations (Put/Delete), Memstore, and Coprocessors to what I'd volunteer
for since I've been in that code a lot.

 From: lars hofhansl <lhofhansl@yahoo.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
Sent: Monday, September 17, 2012 4:13 PM
Subject: Re: DISCUSSION: Component Lieutenants?
Maybe just make it an informal list of (self declared :) ) "specialists". For 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...

If 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 guidelines.

I'd volunteer for: Transactions/MVCC, Scanners/Scanning/QueryMatcher, Client, Deletion, Performance.

From: Andrew Purtell <andrew.purtell@gmail.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl <lhofhansl@yahoo.com>

Sent: Monday, September 17, 2012 3:08 PM
Subject: Re: DISCUSSION: Component Lieutenants?

Why doesn't every committer or contributor with interest volunteer? Some overlap there would
be good. Beyond that we can list the remaining areas without good coverage and nominate for

I volunteer for Coprocessors, REST, security, filters, and client. 

On Sep 17, 2012, at 2:12 PM, Todd Lipcon <todd@cloudera.com> wrote:

> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:
>> I like that idea.
>> Should all PMC members or committers be at top level of the source tree? Or will
that just take us back to the status-quo?
> I feel like that would take us back to the status quo.
> The downside of this proposal is that we should probably have some
> well-principled way of determining who gets "ownership" (whether
> co-ownership or alone) of each part of the heirarchy. I fear it could
> become political or discourage people from contributing or reviewing
> code outside their area of expertise. So, if people have good ideas on
> how to go about doing this, please shout them out!
>> I certainly like that a typical patch then will involve multiple reviewer, and it
will be more defined who should look at what patch.
>> -- Lars
>> ----- Original Message -----
>> From: Todd Lipcon <todd@cloudera.com>
>> To: dev@hbase.apache.org
>> Cc:
>> Sent: Friday, September 14, 2012 1:15 PM
>> Subject: Re: DISCUSSION: Component Lieutenants?
>> I like the idea of lieutenants, but another option would be a
>> "multi-lieutenant" model.
>> The model used at google is that each directory has a file called
>> "OWNERS" which lists several usernames, one per line.
>> For any given patch, you are expected to get a review such that, for
>> each modified file, one of the OWNERS listed in that directory (or any
>> parent thereof) has +1ed.
>> So, for example, imagine that hbase/OWNERS has only Stack, and
>> hbase/foo/component1/OWNERS has "jxiang,larsh". If I make a patch
>> which touches something in foo/component1/bar/, I'd need a review from
>> at least one of Jimmy, Lars, or Stack.
>> The assumption is that you try to get review from the most specific
>> owner, but if those people are MIA, you get review from someone higher
>> up the stack. The multi-person-per-dir model also ensures that, if
>> someone's on vacation or otherwise busy, we don't get blocked. And it
>> formalizes in the actual source tree who you should probably email if
>> you have questions about an area.
>> It also means that wide-ranging patches that touch multiple components
>> need a lot of reviewers (or someone higher up the chain of command who
>> has "permission" on the whole tree). So if I had a mondo patch that
>> touched the region server, the master, and the IPC layer, I'd probably
>> need at least three separate people to sign off.
>> Whatever we do, rather than making it a strict policy, let's start out
>> with a soft touch. Perhaps declare the component maintainers and try
>> to pick reviewers based on the criteria. But if people are busy and
>> work needs to get done, we don't need to be anal about it :)
>> -Todd
>> On Fri, Sep 14, 2012 at 12:17 PM, Stack <stack@duboce.net> wrote:
>>> At the contributor's pow wow a few days ago [1], during a discussion
>>> about whether or not commits should have more friction applied -- i.e.
>>> have more review before they go in -- it was thought that we might
>>> benefit if we had "lieutenants" over-seeing individual HBase
>>> components.  A lieutenant would be someone who has an interest and an
>>> understanding of how a particular component works (or should work).  A
>>> lieutenant does not need to be a committer.  Before committing a patch
>>> that touched on a particular component, the patch would have to have
>>> been +1'd by the component lieutenant before it could go in (or if the
>>> lieutenant is MIA, it was suggested by the Mighty Jon Hsieh that two
>>> +1s by other contributors/committers would do instead; this latter
>>> rule would probably also apply when a patch spanned components).
>>> We already have a few folks signed up, knowingly or otherwise, as
>>> component owners [1].
>>> What do folks think?
>>> Should we go ahead w/ this project?  If so, any volunteers (I signed
>>> up a few of the obvious component leads)?  I can add you as component
>>> lieutenant into JIRA.  We can add more components if you don't see
>>> your interest listed.
>>> St.Ack
>>> 1. http://www.meetup.com/hbaseusergroup/events/80621872/
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
> -- 
> Todd Lipcon
> Software Engineer, Cloudera
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message