Owen O'Malley
2010-08-16, 21:38
Arun C Murthy
2010-08-16, 21:43
Jakob Homan
2010-08-16, 21:58
Doug Cutting
2010-08-16, 22:37
Nigel Daley
2010-08-16, 23:51
Hemanth Yamijala
2010-08-17, 06:14
Steve Loughran
2010-08-17, 16:07
Tom White
2010-08-17, 16:10
Chris Douglas
2010-08-17, 17:17
Tsz Wo \
2010-08-17, 17:28
Daniel Jue
2010-08-17, 17:41
Konstantin Boudnik
2010-08-17, 18:03
Konstantin Shvachko
2010-08-18, 17:59
Owen O'Malley
2010-08-18, 18:19
Stack
2010-08-19, 18:40
Chris Douglas
2010-08-20, 21:46
Owen O'Malley
2010-08-23, 21:40
-
[VOTE] Should we define the Common committers as HDFS + MapReduce committers?Owen O'Malley 2010-08-16, 21:38
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
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?Arun C Murthy 2010-08-16, 21:43
+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
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?Jakob Homan 2010-08-16, 21:58
+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
>
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?Doug Cutting 2010-08-16, 22:37
+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
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?Nigel Daley 2010-08-16, 23:51
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
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?Hemanth Yamijala 2010-08-17, 06:14
+1
Thanks
Hemanth
On Tue, Aug 17, 2010 at 3:08 AM, Owen O'Malley <[EMAIL PROTECTED]> 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
>
Thanks
Hemanth
On Tue, Aug 17, 2010 at 3:08 AM, Owen O'Malley <[EMAIL PROTECTED]> 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?Steve Loughran 2010-08-17, 16:07
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 ...
> 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?Tom White 2010-08-17, 16:10
+1
Tom
On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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
>
Tom
On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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?Chris Douglas 2010-08-17, 17:17
+1 -C
On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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
>
On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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?Tsz Wo \ 2010-08-17, 17:28
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 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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
>
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 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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?Daniel Jue 2010-08-17, 17:41
+1
On Tue, Aug 17, 2010 at 1:28 PM, Tsz Wo (Nicholas), Sze
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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
>>
>
>
On Tue, Aug 17, 2010 at 1:28 PM, Tsz Wo (Nicholas), Sze
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> 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?Konstantin Boudnik 2010-08-17, 18:03
+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 <[EMAIL PROTECTED]> 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
> >
On Tue, Aug 17, 2010 at 03:16AM, Chris Douglas wrote:
> +1
>
> On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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?Konstantin Shvachko 2010-08-18, 17:59
+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
>
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?Owen O'Malley 2010-08-18, 18:19
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?Stack 2010-08-19, 18:40
+1
On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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
>
On Mon, Aug 16, 2010 at 2:38 PM, Owen O'Malley <[EMAIL PROTECTED]> 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?Chris Douglas 2010-08-20, 21:46
+1: Owen, Arun, Doug, Nigel, Hemanth, Chris, Tom, Nicholas,
Konstantin, Stack, (Jakob), (Cos), (Daniel)
The vote passes.
Thanks to everyone who voted. -C
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?Owen O'Malley 2010-08-23, 21:40
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
