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?
Ted Yu 2012-09-18, 04:05
I volunteer for snapshots and WAL components.

Thanks

On Mon, Sep 17, 2012 at 4:13 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> Maybe just make it an informal list of (self declared :) ) "specialists".
> For example if I see changes in the Assignment code that I do not
> understand I usually defer to Ram. If there's some HFile stuff, I defer to
> Mikhail...
>
> If we had a list of specialists, it would be easier to defer to them, or
> to pull them into a review. I think that would be better than strict
> guidelines.
>
>
> I'd volunteer for: Transactions/MVCC, Scanners/Scanning/QueryMatcher,
> Client, Deletion, Performance.
>
>
>
> ________________________________
>  From: Andrew Purtell <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
> [EMAIL PROTECTED]>
> Sent: Monday, September 17, 2012 3:08 PM
> Subject: Re: DISCUSSION: Component Lieutenants?
>
> Why doesn't every committer or contributor with interest volunteer? Some
> overlap there would be good. Beyond that we can list the remaining areas
> without good coverage and nominate for them?
>
> I volunteer for Coprocessors, REST, security, filters, and client.
>
> On 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
> >> 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