hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [VOTE] - Establish YARN as a sub-project of Apache Hadoop
Date Fri, 24 Aug 2012 04:08:27 GMT
Will do.  Not sure we can do a single vote with multiple options since
it represents a change to the bylaws and it would be possible for both
votes to pass.  I'll start a vote for #3 and if that fails someone can
start a vote for #2.


On Thu, Aug 23, 2012 at 7:11 PM, Vinod Kumar Vavilapalli
<vinodkv@hortonworks.com> wrote:
> 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>
>>>>>> 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

View raw message