I can add the HalfStoreFile related things that happens after split. (forgot to add last time)
Regards Ram > -----Original Message----- > From: Jonathan Hsieh [mailto:j...@cloudera.com] > Sent: Tuesday, September 18, 2012 12:45 PM > To: dev@hbase.apache.org > Subject: Re: DISCUSSION: Component Lieutenants? > > For me, I'd say hbck, copytable, snapshots, and likely assignment soon. > > Jon. > > On Mon, Sep 17, 2012 at 9:22 PM, Ramkrishna.S.Vasudevan < > ramkrishna.vasude...@huawei.com> wrote: > > > 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:yuzhih...@gmail.com] > > > Sent: Tuesday, September 18, 2012 9:36 AM > > > To: dev@hbase.apache.org; 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 > <lhofha...@yahoo.com> > > > 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 <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 > > > > > > > > > > > -- > // Jonathan Hsieh (shay) > // Software Engineer, Cloudera > // j...@cloudera.com
