hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: DISCUSSION: Component Lieutenants?
Date Tue, 18 Sep 2012 20:25:27 GMT
-1s should always act as vetos

-Todd

On Tue, Sep 18, 2012 at 1:24 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> What if we have a +1 from someone on the list and at the same time a -1
> from someone off the list ?
>
> Cheers
>
> On Tue, Sep 18, 2012 at 12:47 PM, Andrew Purtell <apurtell@apache.org>wrote:
>
>> I agree. I think those listed on the component should be those to ping for
>> a review but it's just that... With the expectation that such volunteers
>> will do reviews as needed. And a +1 from any on the list will do, or two
>> +1s from any committer.
>>
>> If we have too many volunteers in one area and not enough in another, let's
>> allow Stack to spread some effort around.
>>
>> On Tuesday, September 18, 2012, Gregory Chanan wrote:
>>
>> > How are we deciding what counts as a component?  Based on what people say
>> > here?  Some of these seem vastly different in scope (e.g. Client vs
>> > HalfStoreFile).
>> >
>> > Also, will it be obvious, from the JIRA, who I need to get reviews from
>> and
>> > how many?  From Stack's e-mail it sounds like clicking on the component
>> > will give you a list of names; perhaps we should make it explicit in that
>> > link that one +1 is enough for anyone on this list, otherwise two +1s are
>> > necessary.  We need to make it clear what the process is for new
>> > contributors (more process is okay, but it needs to be fair and
>> explicit).
>> >
>> > What about patches that touch more than one component?
>> >
>> > Greg
>> >
>> > On Tue, Sep 18, 2012 at 11:58 AM, 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 <
>>
>>
>>
>> --
>> Best regards,
>>
>>    - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>



-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
View raw message