hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kumar Vavilapalli <vino...@hortonworks.com>
Subject Re: [VOTE] - Establish YARN as a sub-project of Apache Hadoop
Date Fri, 24 Aug 2012 02:11:10 GMT

Thanks for the clarification.

Seems like we can start a vote on those lines. But let's do that separately on a fresh thread.
This one has stretched for far too long after the original vote thread concluded.

Thanks,
+Vinod

On Aug 23, 2012, at 11:33 AM, Eli Collins wrote:

> On Thu, Aug 23, 2012 at 11:13 AM, Vinod Kumar Vavilapalli
> <vinodkv@hortonworks.com> wrote:
>> 
>> On Aug 22, 2012, at 11:43 AM, Eli Collins wrote:
>> 
>>> On Wed, Aug 22, 2012 at 11:38 AM, Doug Cutting <cutting@apache.org> wrote:
>>>>> 2. Distinct MR, HDFS and YARN committers
>>>>> 3. Combine MR, YARN, HDFS committers
>>>> 
>>>> So we might better just vote on (2)
>>>> versus (3)?
>>> 
>>> Works for me.  What do others think?
>> 
>> Can you clarify more on what you are proposing we vote on?
>> 
>> What does (2) mean?
> 
> "Distinct MR, HDFS and YARN committers" means that MR, HDFS, and YARN
> each have their own set of committers. Today we have two sets (MR and
> HDFS) so under this option we would have three sets of committers.
> (And technically a 4th set which is the PMC which is shared across
> sub-projects and can commit to all of them).
> 
>> Since (1) was dropped, does it mean we seed the YARN list with folks who have been
contributing/reviewing patches on YARN?
> 
> The vote would need to spell out how we would seed the YARN list. Per
> above I'd suggest seeding it with the current MR committers - ie the
> people who can commit to YARN today - there's no need to actively
> exclude people we already trust to commit to this code, and there's
> obvious downside to excluding them, for example, some patches need to
> span sub-projects (same reason all HDFS/MR committers can commit to
> Common).  If/when the sub-projects become TLPs (ie when there are real
> distinct boundaries between the projects) seems like a good time to
> divvy things up.
> 
> Personally I'm in favor of #3, I liked Chris D's original proposal to
> just merge all the committer lists and call it a day!
> 
> Thanks,
> Eli


Mime
View raw message