Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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?
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB