hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Himanshu Vashishtha <hvash...@cs.ualberta.ca>
Subject Re: DISCUSSION: Component Lieutenants?
Date Tue, 18 Sep 2012 19:33:18 GMT
+1 for trying this out.

I'd like to volunteer for io, replication, and coprocessors (ACL, security).

Himanshu

On Tue, Sep 18, 2012 at 12:58 PM, Amandeep Khurana <amansk@gmail.com> wrote:
> I'd like to volunteer for client, tools (copytable, export/import, etc and
> others that will come up in the future).
>
> On Tue, Sep 18, 2012 at 2:47 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:
>
>> I'd add WAL/HLog, Mutations (Put/Delete), Memstore, and Coprocessors to
>> what I'd volunteer for since I've been in that code a lot.
>>
>>
>>
>> ________________________________
>>  From: lars hofhansl <lhofhansl@yahoo.com>
>> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
>> Sent: Monday, September 17, 2012 4:13 PM
>> Subject: Re: DISCUSSION: Component Lieutenants?
>>
>> 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 <andrew.purtell@gmail.com>
>> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
>> Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl <
>> lhofhansl@yahoo.com>
>> 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 <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
>>

Mime
View raw message