+1 to component partitioning, not source layout. My earlier volunteering was by-component.
On Sep 17, 2012, at 3:08 PM, Jonathan Hsieh <j...@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 <t...@cloudera.com> wrote: > >> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <lhofha...@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 <t...@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 <st...@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 > // j...@cloudera.com
