hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: DISCUSSION: Component Lieutenants?
Date Mon, 17 Sep 2012 22:10:36 GMT
+1 to component partitioning, not source layout. My earlier volunteering was by-component.


On Sep 17, 2012, at 3:08 PM, Jonathan Hsieh <jon@cloudera.com> 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 <todd@cloudera.com> wrote:
> 
>> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <lhofhansl@yahoo.com>
>> 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 <todd@cloudera.com>
>>> To: dev@hbase.apache.org
>>> 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
>>> touched the region server, the master, and the IPC layer, I'd probably
>>> need at least three separate people to sign off.
>>> 
>>> 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 :)
>>> 
>>> -Todd
>>> 
>>> On Fri, Sep 14, 2012 at 12:17 PM, Stack <stack@duboce.net> wrote:
>>>> At the contributor's pow wow a few days ago [1], during a discussion
>>>> about whether or not commits should have more friction applied -- i.e.
>>>> have more review before they go in -- it was thought that we might
>>>> benefit if we had "lieutenants" over-seeing individual HBase
>>>> components.  A lieutenant would be someone who has an interest and an
>>>> understanding of how a particular component works (or should work).  A
>>>> lieutenant does not need to be a committer.  Before committing a patch
>>>> that touched on a particular component, the patch would have to have
>>>> been +1'd by the component lieutenant before it could go in (or if the
>>>> lieutenant is MIA, it was suggested by the Mighty Jon Hsieh that two
>>>> +1s by other contributors/committers would do instead; this latter
>>>> rule would probably also apply when a patch spanned components).
>>>> 
>>>> We already have a few folks signed up, knowingly or otherwise, as
>>>> component owners [1].
>>>> 
>>>> What do folks think?
>>>> 
>>>> Should we go ahead w/ this project?  If so, any volunteers (I signed
>>>> up a few of the obvious component leads)?  I can add you as component
>>>> lieutenant into JIRA.  We can add more components if you don't see
>>>> your interest listed.
>>>> 
>>>> St.Ack
>>>> 
>>>> 1. http://www.meetup.com/hbaseusergroup/events/80621872/
>>> 
>>> 
>>> 
>>> --
>>> Todd Lipcon
>>> Software Engineer, Cloudera
>>> 
>> 
>> 
>> 
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>> 
> 
> 
> 
> -- 
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com

Mime
View raw message