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?
Ramkrishna.S.Vasudevan 2012-09-18, 04:22
I can volunteer for Assignments( though the trunk code I need some more
hands on),
Split regions, HLog replay.

Regards
Ram

> -----Original Message-----
> From: Ted Yu [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2012 9:36 AM
> To: [EMAIL PROTECTED]; lars hofhansl
> Subject: Re: DISCUSSION: Component Lieutenants?
>
> 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