Stack
2012-09-14, 19:17
Todd Lipcon
2012-09-14, 20:15
lars hofhansl
2012-09-15, 04:15
Todd Lipcon
2012-09-17, 21:12
Andrew Purtell
2012-09-17, 22:08
lars hofhansl
2012-09-17, 23:13
Ted Yu
2012-09-18, 04:05
Ramkrishna.S.Vasudevan
2012-09-18, 04:22
Jonathan Hsieh
2012-09-17, 22:08
Stack
2012-09-18, 04:00
Andrew Purtell
2012-09-17, 22:10
Stack
2012-09-15, 03:57
Stack
2013-01-08, 18:44
-
DISCUSSION: Component Lieutenants?Stack 2012-09-14, 19:17
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/
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/
+
Stack 2012-09-14, 19:17
-
Re: DISCUSSION: Component Lieutenants?Todd Lipcon 2012-09-14, 20:15
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 <[EMAIL PROTECTED]> 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
"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 <[EMAIL PROTECTED]> 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 2012-09-14, 20:15
-
Re: DISCUSSION: Component Lieutenants?lars hofhansl 2012-09-15, 04:15
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 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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
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 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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
+
lars hofhansl 2012-09-15, 04:15
-
Re: DISCUSSION: Component Lieutenants?Todd Lipcon 2012-09-17, 21:12
On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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
Todd Lipcon
Software Engineer, Cloudera
> 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 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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
Todd Lipcon
Software Engineer, Cloudera
+
Todd Lipcon 2012-09-17, 21:12
-
Re: DISCUSSION: Component Lieutenants?Andrew Purtell 2012-09-17, 22:08
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 <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> 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).
I volunteer for Coprocessors, REST, security, filters, and client.
On Sep 17, 2012, at 2:12 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> 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).
+
Andrew Purtell 2012-09-17, 22:08
-
Re: DISCUSSION: Component Lieutenants?lars hofhansl 2012-09-17, 23:13
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 <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> wrote:
>>> At the contributor's pow wow a few days ago [1], during a discussion
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 <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]> wrote:
>>> At the contributor's pow wow a few days ago [1], during a discussion
+
lars hofhansl 2012-09-17, 23:13
-
Re: DISCUSSION: Component Lieutenants?Ted Yu 2012-09-18, 04:05
I volunteer for snapshots and WAL components.
Thanks
On Mon, Sep 17, 2012 at 4:13 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
> [EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> >> To: [EMAIL PROTECTED]
> >> 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
Thanks
On Mon, Sep 17, 2012 at 4:13 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
> [EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> >> To: [EMAIL PROTECTED]
> >> 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
+
Ted Yu 2012-09-18, 04:05
-
RE: DISCUSSION: Component Lieutenants?Ramkrishna.S.Vasudevan 2012-09-18, 04:22
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:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2012 9:36 AM
> To: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
> > [EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl
> <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > >> To: [EMAIL PROTECTED]
> > >> 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
hands on),
Split regions, HLog replay.
Regards
Ram
> -----Original Message-----
> From: Ted Yu [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2012 9:36 AM
> To: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
> > [EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl
> <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > >> To: [EMAIL PROTECTED]
> > >> 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
+
Ramkrishna.S.Vasudevan 2012-09-18, 04:22
-
Re: DISCUSSION: Component Lieutenants?Jonathan Hsieh 2012-09-17, 22:08
I like Todd's idea in principle but I think there are some problems with
the organization of the code base currently that make this potentially
painful today (did you look at how much code is in hmaster and
regionserver?). Also some folk's expertise doesn't lay in one hierarchical
tree necessarily. Because of this I prefer having it per component. For
areas where components are a little broad (master, regionserver) we could
break them down a little more. If we actually start using components
consistently it also makes it easier for us to setup jira filters for the
review queues.
I do like the idea of multiple people "owning" an area to avoid
politicking. For lookup purposes, instead of putting names under a
component lead, we could just use the description field to list folk's name.
https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
get when you click on the rest component link)
https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
get when you click on the hbck component link)
To initially dole out components, we could do it the benevolent dictator
way (stack's velvet glove initially assigns folks), and then folks in the
component can add others. (likely criteria are similar to commit --
designs docs presented, authorship of patches, support on mailing list).
If we add components (like snapshots recently), the authors and authors of
design docs folks get to own it initially. I think one that that is
important some sort of design info up so that we know how things are
supposed to work.
Jon.
On Mon, Sep 17, 2012 at 2:12 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > 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
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]
the organization of the code base currently that make this potentially
painful today (did you look at how much code is in hmaster and
regionserver?). Also some folk's expertise doesn't lay in one hierarchical
tree necessarily. Because of this I prefer having it per component. For
areas where components are a little broad (master, regionserver) we could
break them down a little more. If we actually start using components
consistently it also makes it easier for us to setup jira filters for the
review queues.
I do like the idea of multiple people "owning" an area to avoid
politicking. For lookup purposes, instead of putting names under a
component lead, we could just use the description field to list folk's name.
https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
get when you click on the rest component link)
https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
get when you click on the hbck component link)
To initially dole out components, we could do it the benevolent dictator
way (stack's velvet glove initially assigns folks), and then folks in the
component can add others. (likely criteria are similar to commit --
designs docs presented, authorship of patches, support on mailing list).
If we add components (like snapshots recently), the authors and authors of
design docs folks get to own it initially. I think one that that is
important some sort of design info up so that we know how things are
supposed to work.
Jon.
On Mon, Sep 17, 2012 at 2:12 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > 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
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]
+
Jonathan Hsieh 2012-09-17, 22:08
-
Re: DISCUSSION: Component Lieutenants?Stack 2012-09-18, 04:00
On Mon, Sep 17, 2012 at 3:08 PM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
> I do like the idea of multiple people "owning" an area to avoid
> politicking.
Yes, multi-owners if possible is the way to go. A +1 by a multi-owner
or two +1s by non-multi-owners before a patch goes into a particular
component.
> For lookup purposes, instead of putting names under a
> component lead, we could just use the description field to list folk's name.
> https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
> get when you click on the rest component link)
> https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
> get when you click on the hbck component link)
>
Good one Jon. I actually want to go ahead and do this now and move
over the ownerships we already have and add the ones that you and Lars
just volunteered for.
> To initially dole out components, we could do it the benevolent dictator
> way (stack's velvet glove initially assigns folks), and then folks in the
> component can add others.
Smile. Or better would be folks volunteering (as fellas are doing
here already). I can take care of updating JIRA.
> I think one that that is
> important some sort of design info up so that we know how things are
> supposed to work.
>
I agree.
If it were in place, it'd make it easier rejecting patches that take
us away from the stated goal. It'd also serve as a target for patches
to drive toward.
Who'd do the design or component tenets list? Component owner's
ideally, when they get a moment.
St.Ack
> I do like the idea of multiple people "owning" an area to avoid
> politicking.
Yes, multi-owners if possible is the way to go. A +1 by a multi-owner
or two +1s by non-multi-owners before a patch goes into a particular
component.
> For lookup purposes, instead of putting names under a
> component lead, we could just use the description field to list folk's name.
> https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
> get when you click on the rest component link)
> https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
> get when you click on the hbck component link)
>
Good one Jon. I actually want to go ahead and do this now and move
over the ownerships we already have and add the ones that you and Lars
just volunteered for.
> To initially dole out components, we could do it the benevolent dictator
> way (stack's velvet glove initially assigns folks), and then folks in the
> component can add others.
Smile. Or better would be folks volunteering (as fellas are doing
here already). I can take care of updating JIRA.
> I think one that that is
> important some sort of design info up so that we know how things are
> supposed to work.
>
I agree.
If it were in place, it'd make it easier rejecting patches that take
us away from the stated goal. It'd also serve as a target for patches
to drive toward.
Who'd do the design or component tenets list? Component owner's
ideally, when they get a moment.
St.Ack
+
Stack 2012-09-18, 04:00
-
Re: DISCUSSION: Component Lieutenants?Andrew Purtell 2012-09-17, 22:10
+1 to component partitioning, not source layout. My earlier volunteering was by-component.
On Sep 17, 2012, at 3:08 PM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
> I like Todd's idea in principle but I think there are some problems with
> the organization of the code base currently that make this potentially
> painful today (did you look at how much code is in hmaster and
> regionserver?). Also some folk's expertise doesn't lay in one hierarchical
> tree necessarily. Because of this I prefer having it per component. For
> areas where components are a little broad (master, regionserver) we could
> break them down a little more. If we actually start using components
> consistently it also makes it easier for us to setup jira filters for the
> review queues.
>
> I do like the idea of multiple people "owning" an area to avoid
> politicking. For lookup purposes, instead of putting names under a
> component lead, we could just use the description field to list folk's name.
> https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
> get when you click on the rest component link)
> https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
> get when you click on the hbck component link)
>
> To initially dole out components, we could do it the benevolent dictator
> way (stack's velvet glove initially assigns folks), and then folks in the
> component can add others. (likely criteria are similar to commit --
> designs docs presented, authorship of patches, support on mailing list).
> If we add components (like snapshots recently), the authors and authors of
> design docs folks get to own it initially. I think one that that is
> important some sort of design info up so that we know how things are
> supposed to work.
>
> Jon.
>
> On Mon, Sep 17, 2012 at 2:12 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>>> To: [EMAIL PROTECTED]
>>> 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
On Sep 17, 2012, at 3:08 PM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
> I like Todd's idea in principle but I think there are some problems with
> the organization of the code base currently that make this potentially
> painful today (did you look at how much code is in hmaster and
> regionserver?). Also some folk's expertise doesn't lay in one hierarchical
> tree necessarily. Because of this I prefer having it per component. For
> areas where components are a little broad (master, regionserver) we could
> break them down a little more. If we actually start using components
> consistently it also makes it easier for us to setup jira filters for the
> review queues.
>
> I do like the idea of multiple people "owning" an area to avoid
> politicking. For lookup purposes, instead of putting names under a
> component lead, we could just use the description field to list folk's name.
> https://issues.apache.org/jira/browse/HBASE/component/12312140 (what you
> get when you click on the rest component link)
> https://issues.apache.org/jira/browse/HBASE/component/12315702 (what you
> get when you click on the hbck component link)
>
> To initially dole out components, we could do it the benevolent dictator
> way (stack's velvet glove initially assigns folks), and then folks in the
> component can add others. (likely criteria are similar to commit --
> designs docs presented, authorship of patches, support on mailing list).
> If we add components (like snapshots recently), the authors and authors of
> design docs folks get to own it initially. I think one that that is
> important some sort of design info up so that we know how things are
> supposed to work.
>
> Jon.
>
> On Mon, Sep 17, 2012 at 2:12 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Sep 14, 2012 at 9:15 PM, lars hofhansl <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>>> To: [EMAIL PROTECTED]
>>> 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
+
Andrew Purtell 2012-09-17, 22:10
-
Re: DISCUSSION: Component Lieutenants?Stack 2012-09-15, 03:57
On Fri, Sep 14, 2012 at 1:15 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> 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.
>
Seems like a nice model to me. I can't use JIRA to implement the
hierarchy. This page,
https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components,
only lets me have one person per component and it does not let me
specify a supra-layer above components to which I could add a
captains' layer.
We could do the hierarchy in a wiki page if folks like Todds suggestion above.
> 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 :)
>
Agreed.
St.Ack
> 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.
>
Seems like a nice model to me. I can't use JIRA to implement the
hierarchy. This page,
https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components,
only lets me have one person per component and it does not let me
specify a supra-layer above components to which I could add a
captains' layer.
We could do the hierarchy in a wiki page if folks like Todds suggestion above.
> 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 :)
>
Agreed.
St.Ack
+
Stack 2012-09-15, 03:57
-
Re: DISCUSSION: Component Lieutenants?Stack 2013-01-08, 18:44
How do we think this 'component owner' project (or 'component guide' or
'component shepherd' or 'captain' *) [1] is going? I see the definite
emergence of recognized domain experts consulted whenever a significant
patch touches their area (for example, Jimmy being consulted whenever
Assignment is touched, etc.). This is good. Lets have more of this
(smile).
We do seem to be accumulating a good backlog of patches in need of review.
What do we think we can do about that? If issues were assigned to a
component, would it be fair that component owners at least register the
submission perhaps prioritizing or even doing first a first pass on the
issue**?
St.Ack
P.S. Anyone can volunteer to take on a component -- just write me off list
and I'll update JIRA accordingly (as per [1]).
* I made note of this 'component owner' project of ours when I sent in our
last hbase report. Two folks objected that 'owner' is exclusionary.
Suggestions for alternate names welcome. I'll update the doc,
http://hbase.apache.org/book.html#OWNER, accordingly.
** I think we need to do a better job assigning priorities to issues and
working on higher priority issues first. Priority seems to mean little
going by what folks are working on, on cursory survey, so its tough getting
a sense of what is important just by looking at JIRA.
1. http://hbase.apache.org/book.html#OWNER
On Thu, Sep 20, 2012 at 3:42 PM, Stack <[EMAIL PROTECTED]> wrote:
> I made a first pass on assign component owners:
>
> https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components
>
> I signed you all up for whatever you volunteered for. Let me know if
> you'd have me edit it otherwise.
>
> I removed a few components (mapred -- we have mapreduce) and added a
> few new ones; e.g. protobuf.
>
> St.Ack
>
'component shepherd' or 'captain' *) [1] is going? I see the definite
emergence of recognized domain experts consulted whenever a significant
patch touches their area (for example, Jimmy being consulted whenever
Assignment is touched, etc.). This is good. Lets have more of this
(smile).
We do seem to be accumulating a good backlog of patches in need of review.
What do we think we can do about that? If issues were assigned to a
component, would it be fair that component owners at least register the
submission perhaps prioritizing or even doing first a first pass on the
issue**?
St.Ack
P.S. Anyone can volunteer to take on a component -- just write me off list
and I'll update JIRA accordingly (as per [1]).
* I made note of this 'component owner' project of ours when I sent in our
last hbase report. Two folks objected that 'owner' is exclusionary.
Suggestions for alternate names welcome. I'll update the doc,
http://hbase.apache.org/book.html#OWNER, accordingly.
** I think we need to do a better job assigning priorities to issues and
working on higher priority issues first. Priority seems to mean little
going by what folks are working on, on cursory survey, so its tough getting
a sense of what is important just by looking at JIRA.
1. http://hbase.apache.org/book.html#OWNER
On Thu, Sep 20, 2012 at 3:42 PM, Stack <[EMAIL PROTECTED]> wrote:
> I made a first pass on assign component owners:
>
> https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components
>
> I signed you all up for whatever you volunteered for. Let me know if
> you'd have me edit it otherwise.
>
> I removed a few components (mapred -- we have mapreduce) and added a
> few new ones; e.g. protobuf.
>
> St.Ack
>
+
Stack 2013-01-08, 18:44
