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
+
Jonathan Hsieh 2012-09-17, 22:08
+
Stack 2012-09-18, 04:00
Copy link to this message
-
Re: DISCUSSION: Component Lieutenants?
Andrew Purtell 2012-09-17, 22:10
+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]>
>>> To: [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
+
Stack 2012-09-15, 03:57
+
Stack 2013-01-08, 18:44