You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@hadoop.apache.org by Owen O'Malley <om...@apache.org> on 2010/08/16 23:38:53 UTC

[VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Since the project split, it is mostly required that any MapReduce or  
HDFS committers have access to change Common. We haven't had any cases  
where we wanted to nominate any one for just Common. Toward the goal  
of simplifying the structure, I'd propose that we define the Common  
committers as precisely the union of the HDFS committers and MapReduce  
committers.

Clearly, I'm +1.

-- Owen

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Steve Loughran <st...@apache.org>.
On 16/08/10 22:38, Owen O'Malley wrote:
> Since the project split, it is mostly required that any MapReduce or
> HDFS committers have access to change Common. We haven't had any cases
> where we wanted to nominate any one for just Common. Toward the goal of
> simplifying the structure, I'd propose that we define the Common
> committers as precisely the union of the HDFS committers and MapReduce
> committers.
>
> Clearly, I'm +1.
>
> -- Owen

+1

steve. Presumably this means I need to read the hdfs-dev and mapred-dev 
lists too ...

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Nigel Daley <nd...@mac.com>.
Doug, I don't think that's what this vote is doing.  It's not giving all committers access to HDFS + MR + Common.  It seems to be just making committers for Common the union of HDFS and MR.

I'm +1 on the vote.

Nige

On Aug 16, 2010, at 3:37 PM, Doug Cutting wrote:

> +1 I believe that so long as we have synchronized releases then we're co-developing a single product and should be a single community.
> 
> Doug
> 
> On 08/16/2010 02:38 PM, Owen O'Malley wrote:
>> Since the project split, it is mostly required that any MapReduce or
>> HDFS committers have access to change Common. We haven't had any cases
>> where we wanted to nominate any one for just Common. Toward the goal of
>> simplifying the structure, I'd propose that we define the Common
>> committers as precisely the union of the HDFS committers and MapReduce
>> committers.
>> 
>> Clearly, I'm +1.
>> 
>> -- Owen


Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Doug Cutting <cu...@apache.org>.
+1 I believe that so long as we have synchronized releases then we're 
co-developing a single product and should be a single community.

Doug

On 08/16/2010 02:38 PM, Owen O'Malley wrote:
> Since the project split, it is mostly required that any MapReduce or
> HDFS committers have access to change Common. We haven't had any cases
> where we wanted to nominate any one for just Common. Toward the goal of
> simplifying the structure, I'd propose that we define the Common
> committers as precisely the union of the HDFS committers and MapReduce
> committers.
>
> Clearly, I'm +1.
>
> -- Owen

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Daniel Jue <te...@gmail.com>.
+1

On Tue, Aug 17, 2010 at 1:28 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> It is possibly to have contributors who are only interested in RPC,
> serialization, compression, etc.  However, just as Owen mentioned, we don't have
> such cases yet.  We might decide how to accommodate these contributors when we
> have such cases.
>
> +1
>
> Nicholas
>
>
>
>
> ----- Original Message ----
>> From: Owen O'Malley <om...@apache.org>
>> To: general@hadoop.apache.org
>> Sent: Mon, August 16, 2010 2:38:53 PM
>> Subject: [VOTE] Should we define the Common committers as HDFS + MapReduce
>>committers?
>>
>> Since the project split, it is mostly required that any MapReduce or HDFS
>>committers have access to change Common. We haven't had any cases where we
>>wanted to nominate any one for just Common. Toward the goal of simplifying the
>>structure, I'd propose that we define the Common committers as precisely the
>>union of the HDFS committers and MapReduce committers.
>>
>> Clearly, I'm  +1.
>>
>> -- Owen
>>
>
>

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>.
It is possibly to have contributors who are only interested in RPC, 
serialization, compression, etc.  However, just as Owen mentioned, we don't have 
such cases yet.  We might decide how to accommodate these contributors when we 
have such cases.

+1

Nicholas




----- Original Message ----
> From: Owen O'Malley <om...@apache.org>
> To: general@hadoop.apache.org
> Sent: Mon, August 16, 2010 2:38:53 PM
> Subject: [VOTE] Should we define the Common committers as HDFS + MapReduce 
>committers?
> 
> Since the project split, it is mostly required that any MapReduce or HDFS  
>committers have access to change Common. We haven't had any cases where we  
>wanted to nominate any one for just Common. Toward the goal of simplifying the  
>structure, I'd propose that we define the Common committers as precisely the  
>union of the HDFS committers and MapReduce committers.
> 
> Clearly, I'm  +1.
> 
> -- Owen
> 


Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Owen O'Malley <om...@apache.org>.
On Aug 20, 2010, at 2:46 PM, Chris Douglas wrote:

> The vote passes.

Ok, I've removed the common committer list and replaced it with the  
union of the HDFS and MapReduce committer lists.

-- Owen

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Chris Douglas <cd...@apache.org>.
+1: Owen, Arun, Doug, Nigel, Hemanth, Chris, Tom, Nicholas,
Konstantin, Stack, (Jakob), (Cos), (Daniel)

The vote passes.

Thanks to everyone who voted. -C

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Stack <st...@duboce.net>.
+1

On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <om...@apache.org> wrote:
> Since the project split, it is mostly required that any MapReduce or HDFS
> committers have access to change Common. We haven't had any cases where we
> wanted to nominate any one for just Common. Toward the goal of simplifying
> the structure, I'd propose that we define the Common committers as precisely
> the union of the HDFS committers and MapReduce committers.
>
> Clearly, I'm +1.
>
> -- Owen
>

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Jakob Homan <jh...@yahoo-inc.com>.
+1
Jakob
Arun C Murthy wrote:
> +1
> 
> Arun
> 
> On Aug 16, 2010, at 2:38 PM, Owen O'Malley wrote:
> 
>> Since the project split, it is mostly required that any MapReduce or
>> HDFS committers have access to change Common. We haven't had any cases
>> where we wanted to nominate any one for just Common. Toward the goal
>> of simplifying the structure, I'd propose that we define the Common
>> committers as precisely the union of the HDFS committers and MapReduce
>> committers.
>>
>> Clearly, I'm +1.
>>
>> -- Owen
> 


Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Arun C Murthy <ac...@yahoo-inc.com>.
+1

Arun

On Aug 16, 2010, at 2:38 PM, Owen O'Malley wrote:

> Since the project split, it is mostly required that any MapReduce or
> HDFS committers have access to change Common. We haven't had any cases
> where we wanted to nominate any one for just Common. Toward the goal
> of simplifying the structure, I'd propose that we define the Common
> committers as precisely the union of the HDFS committers and MapReduce
> committers.
>
> Clearly, I'm +1.
>
> -- Owen


Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Chris Douglas <cd...@apache.org>.
+1 -C

On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <om...@apache.org> wrote:
> Since the project split, it is mostly required that any MapReduce or HDFS
> committers have access to change Common. We haven't had any cases where we
> wanted to nominate any one for just Common. Toward the goal of simplifying
> the structure, I'd propose that we define the Common committers as precisely
> the union of the HDFS committers and MapReduce committers.
>
> Clearly, I'm +1.
>
> -- Owen
>

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Owen O'Malley <om...@apache.org>.
On Aug 18, 2010, at 10:59 AM, Konstantin Shvachko wrote:

> +1
>
> Do I understand correctly, with this proposal there will be no
> common only committers? That is, there will be no committers to
> common who are not either HDFS or MR committers.

Correct. There haven't been any and there doesn't seem to be enough  
stand alone functionality in Common that it seems likely. (ie. a  
Commons only committer wouldn't be able to do enough to be interesting.)

-- Owen

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Konstantin Shvachko <sh...@yahoo-inc.com>.
+1

Do I understand correctly, with this proposal there will be no
common only committers? That is, there will be no committers to
common who are not either HDFS or MR committers.

--Konstantin

On 8/16/2010 2:38 PM, Owen O'Malley wrote:
> Since the project split, it is mostly required that any MapReduce or
> HDFS committers have access to change Common. We haven't had any cases
> where we wanted to nominate any one for just Common. Toward the goal
> of simplifying the structure, I'd propose that we define the Common
> committers as precisely the union of the HDFS committers and MapReduce
> committers.
>
> Clearly, I'm +1.
>
> -- Owen
>


Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Konstantin Boudnik <co...@yahoo-inc.com>.
+1 

On Tue, Aug 17, 2010 at 03:16AM, Chris Douglas wrote:
> +1
> 
> On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <om...@apache.org> wrote:
> > Since the project split, it is mostly required that any MapReduce or HDFS
> > committers have access to change Common. We haven't had any cases where we
> > wanted to nominate any one for just Common. Toward the goal of simplifying
> > the structure, I'd propose that we define the Common committers as precisely
> > the union of the HDFS committers and MapReduce committers.
> >
> > Clearly, I'm +1.
> >
> > -- Owen
> >

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Chris Douglas <cd...@apache.org>.
+1

On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <om...@apache.org> wrote:
> Since the project split, it is mostly required that any MapReduce or HDFS
> committers have access to change Common. We haven't had any cases where we
> wanted to nominate any one for just Common. Toward the goal of simplifying
> the structure, I'd propose that we define the Common committers as precisely
> the union of the HDFS committers and MapReduce committers.
>
> Clearly, I'm +1.
>
> -- Owen
>

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Hemanth Yamijala <yh...@gmail.com>.
+1

Thanks
Hemanth

On Tue, Aug 17, 2010 at 3:08 AM, Owen O'Malley <om...@apache.org> wrote:
> Since the project split, it is mostly required that any MapReduce or HDFS
> committers have access to change Common. We haven't had any cases where we
> wanted to nominate any one for just Common. Toward the goal of simplifying
> the structure, I'd propose that we define the Common committers as precisely
> the union of the HDFS committers and MapReduce committers.
>
> Clearly, I'm +1.
>
> -- Owen
>

Re: [VOTE] Should we define the Common committers as HDFS + MapReduce committers?

Posted by Tom White <to...@cloudera.com>.
+1

Tom

On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <om...@apache.org> wrote:
> Since the project split, it is mostly required that any MapReduce or HDFS
> committers have access to change Common. We haven't had any cases where we
> wanted to nominate any one for just Common. Toward the goal of simplifying
> the structure, I'd propose that we define the Common committers as precisely
> the union of the HDFS committers and MapReduce committers.
>
> Clearly, I'm +1.
>
> -- Owen
>