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

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


Copy link to this message
-
Re: DISCUSSION: Component Lieutenants?
Stack 2012-09-15, 03:57
On Fri, Sep 14, 2012 at 1:15 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> 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.
>

Seems like a nice model to me.  I can't use JIRA to implement the
hierarchy.  This page,
https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components,
 only lets me have one person per component and it does not let me
specify a supra-layer above components to which I could add a
captains' layer.

We could do the hierarchy in a wiki page if folks like Todds suggestion above.

> 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 :)
>

Agreed.

St.Ack