Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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?
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB