hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramkrishna.S.Vasudevan" <ramkrishna.vasude...@huawei.com>
Subject RE: DISCUSSION: Component Lieutenants?
Date Tue, 18 Sep 2012 09:39:10 GMT
I can add the HalfStoreFile related things that happens after split. (forgot
to add last  time)

Regards
Ram

> -----Original Message-----
> From: Jonathan Hsieh [mailto:jon@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.vasudevan@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:yuzhihong@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
> <lhofhansl@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.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
> > > >
> >
> >
> 
> 
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com


Mime
View raw message