Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase, mail # dev - DISCUSSION: Component Lieutenants?


+
Stack 2012-09-14, 19:17
+
Todd Lipcon 2012-09-14, 20:15
+
lars hofhansl 2012-09-15, 04:15
+
Todd Lipcon 2012-09-17, 21:12
Copy link to this message
-
Re: DISCUSSION: Component Lieutenants?
Andrew Purtell 2012-09-17, 22:08
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 them?

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

On Sep 17, 2012, at 2:12 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> 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).
+
lars hofhansl 2012-09-17, 23:13
+
Ted Yu 2012-09-18, 04:05
+
Ramkrishna.S.Vasudevan 2012-09-18, 04:22
+
Jonathan Hsieh 2012-09-17, 22:08
+
Stack 2012-09-18, 04:00
+
Andrew Purtell 2012-09-17, 22:10
+
Stack 2012-09-15, 03:57
+
Stack 2013-01-08, 18:44