+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 <ama...@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 <lhofha...@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 <lhofha...@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.purt...@gmail.com> >> To: "dev@hbase.apache.org" <dev@hbase.apache.org> >> Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl < >> lhofha...@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 <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 >>
