Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> [VOTE] - Establish YARN as a sub-project of Apache Hadoop


Copy link to this message
-
Re: [VOTE] - Establish YARN as a sub-project of Apache Hadoop

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
> <[EMAIL PROTECTED]> wrote:
>>
>> On Aug 22, 2012, at 11:43 AM, Eli Collins wrote:
>>
>>> On Wed, Aug 22, 2012 at 11:38 AM, Doug Cutting <[EMAIL PROTECTED]> 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