Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB