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