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?
+1 to component partitioning, not source layout. My earlier volunteering was by-component.

On Sep 17, 2012, at 3:08 PM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> 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.
> Jon.
> 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