Return-Path: X-Original-To: apmail-hadoop-general-archive@minotaur.apache.org Delivered-To: apmail-hadoop-general-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0126E965C for ; Thu, 23 Aug 2012 19:43:52 +0000 (UTC) Received: (qmail 34133 invoked by uid 500); 23 Aug 2012 19:43:47 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 34033 invoked by uid 500); 23 Aug 2012 19:43:47 -0000 Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@hadoop.apache.org Delivered-To: mailing list general@hadoop.apache.org Received: (qmail 33981 invoked by uid 99); 23 Aug 2012 19:43:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2012 19:43:47 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of java.inder@gmail.com designates 209.85.215.48 as permitted sender) Received: from [209.85.215.48] (HELO mail-lpp01m010-f48.google.com) (209.85.215.48) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2012 19:43:42 +0000 Received: by lagr15 with SMTP id r15so774110lag.35 for ; Thu, 23 Aug 2012 12:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QsTRNm6vp5kZu6IK0ShBbnPf3fce25S75+TyaI+7h14=; b=JeIwkq7Axq3nLCIt/VtADEwBUbmu3IeGJosM2iT7WfX1mvIXEY1IhL4bKgqqUqzNxj a7f5i9MKHfqVyi34ZFrwDJYIGiJo+aXe+r5o+y6251OQivQqEYJLOuAMZD6KoDqexF8a DgP0bE0fkUxHJnFnnNFWhiOO/s/PJlLpryvm/NF6IznjOtLALZQCoBRHJtFhaqhreTDa JQ2lk8sKspJTQ/1Bkrll+iYLR/hKSdpYw+Qv/fQD7DrKTZO+UbFTaFXRoYpZLYFHIsq5 5ViwCa0ZJa2ZaZd+RrbLvqlvIdQJhdNO5iZMpiIzoskFSZ0qnuHTV2XsGfcvY3O/trKa y2SQ== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr2833456lam.38.1345751001061; Thu, 23 Aug 2012 12:43:21 -0700 (PDT) Received: by 10.112.100.161 with HTTP; Thu, 23 Aug 2012 12:43:20 -0700 (PDT) In-Reply-To: References: <7CEACB69-C26A-49A7-8612-9C3B068F083D@hortonworks.com> <78470082-34F2-4301-B8F2-50F66C073757@jpl.nasa.gov> Date: Fri, 24 Aug 2012 01:13:20 +0530 Message-ID: Subject: Re: [VOTE] - Establish YARN as a sub-project of Apache Hadoop From: "Inder.dev Java" To: general@hadoop.apache.org Content-Type: multipart/alternative; boundary=bcaec550b3ae5fd97904c7f41296 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec550b3ae5fd97904c7f41296 Content-Type: text/plain; charset=ISO-8859-1 Vote already started now? Is this also runs for 7 days? -thx On Fri, Aug 24, 2012 at 12:03 AM, Eli Collins wrote: > On Thu, Aug 23, 2012 at 11:13 AM, Vinod Kumar Vavilapalli > wrote: > > > > On Aug 22, 2012, at 11:43 AM, Eli Collins wrote: > > > >> On Wed, Aug 22, 2012 at 11:38 AM, Doug Cutting > 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 > --bcaec550b3ae5fd97904c7f41296--