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
Andrew Purtell 2012-09-17, 22:08
lars hofhansl 2012-09-17, 23:13
Ted Yu 2012-09-18, 04:05
Ramkrishna.S.Vasudevan 2012-09-18, 04:22
Copy link to this message
Re: DISCUSSION: Component Lieutenants?
Jonathan Hsieh 2012-09-17, 22:08
I like Todd's idea in principle but I think there are some problems with
the organization of the code base currently that make this potentially
painful today (did you look at how much code is in hmaster and
regionserver?).  Also some folk's expertise doesn't lay in one hierarchical
tree necessarily.  Because of this I prefer having it per component.  For
areas where components are a little broad (master, regionserver) we could
break them down a little more.  If we actually start using components
consistently it also makes it easier for us to setup jira filters for the
review queues.

I do like the idea of multiple people "owning" an area to avoid
politicking.  For lookup purposes, instead of putting names under a
component lead, we could just use the description field to list folk's name.
https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
get when you click on the rest component link)
https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
get when you click on the hbck component link)

To initially dole out components, we could do it the benevolent dictator
way (stack's velvet glove initially assigns folks), and then folks in the
component can add others.  (likely criteria are similar to commit --
 designs docs presented, authorship of patches, support on mailing list).
 If we add components (like snapshots recently), the authors and authors of
design docs folks get to own it initially.  I think one that that is
important some sort of design info up so that we know how things are
supposed to work.


On Mon, 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]>
> > 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

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
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