hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: DISCUSSION: Component Lieutenants?
Date Sat, 15 Sep 2012 03:57:02 GMT
On Fri, Sep 14, 2012 at 1:15 PM, Todd Lipcon <todd@cloudera.com> 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,
 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 :)



View raw message