From general-return-1982-apmail-hadoop-general-archive=hadoop.apache.org@hadoop.apache.org Wed Aug 18 04:53:30 2010 Return-Path: Delivered-To: apmail-hadoop-general-archive@minotaur.apache.org Received: (qmail 88886 invoked from network); 18 Aug 2010 04:53:29 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Aug 2010 04:53:29 -0000 Received: (qmail 98985 invoked by uid 500); 18 Aug 2010 04:53:28 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 98483 invoked by uid 500); 18 Aug 2010 04:53:25 -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 98475 invoked by uid 99); 18 Aug 2010 04:53:24 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Aug 2010 04:53:24 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yhemanth@gmail.com designates 209.85.212.48 as permitted sender) Received: from [209.85.212.48] (HELO mail-vw0-f48.google.com) (209.85.212.48) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Aug 2010 04:53:01 +0000 Received: by vws4 with SMTP id 4so255394vws.35 for ; Tue, 17 Aug 2010 21:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=wn6yxBx7/J5ykqgev2rMGQw9xgR5t0oJctd0eHMwyy0=; b=JijLVVkLJln8iyQ4i29B83syq1gDA1S1VlbdcxH1nioa9H278qI4T6UfPvKQzgrN3m 4yWP1mIfd9XB02sNx5Vk9Y5ePS7AWab9ZvWOVN0XVW7W2Qo/DtC1bEVkSS4mNbV0XGIu Ipfo46Ll5IlKcvwBrA53dEwrWK3iYMytYpWvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=lJxw15PVtW7oS4JjNzpKeV2sebAJHB3ySf+MHIfHNzPLB1CVzzSOS1VTsJhFNv6HUL BXpIY7GKxMs6gXu2TNjRZBdqJMkgCz2at5fHiy0xG+1d7Nu6vmQ5jYJ1hbeou0emwipY N26y5Sfrpfprdc5lmX8h8Vk8Xij6mfc08DtvM= MIME-Version: 1.0 Received: by 10.220.121.210 with SMTP id i18mr4444629vcr.8.1282107160812; Tue, 17 Aug 2010 21:52:40 -0700 (PDT) Received: by 10.220.178.135 with HTTP; Tue, 17 Aug 2010 21:52:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 10:22:40 +0530 Message-ID: Subject: Re: [VOTE] Combine MapReduce/HDFS Committers From: Hemanth Yamijala To: general@hadoop.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org -1. After thinking through, I do feel that there is and will be a trend where more folks will focus on only one of the two projects. I certainly know of several Map/Reduce committers who are not active on HDFS and vice-versa, and therefore couldn't qualify to have commit rights on both projects. Thanks Hemanth On Tue, Aug 17, 2010 at 3:45 PM, Chris Douglas wrote: > Per the discussion thread: http://s.apache.org/XkY > > Should HDFS and MapReduce committers lists be combined and all > subsequent committers on either of these two projects be granted karma > in the other? > > If the vote passes, current and future committers to MapReduce and > HDFS will gain commit rights in both projects. Commit rights to Common > are unaffected. > > Without bylaws, a 2/3 majority for a committer import seems like a > reasonable bar, given that adding an individual committer requires > consensus. > > ---- > > Owen has started a separate voting thread, proposing to define the > Common committer list as the union of HDFS and MapReduce committers > (vote A), so I tried to write this (vote B) so it would not conflict. > As I'm reading it: > > A passes, B passes: One can become a committer on HDFS or MapReduce. > Commit to either implies commit on HDFS, MR, and Common. > A passes, B fails: One can become a committer on HDFS or MapReduce. > Commit to either implies commit on Common, only. > A fails, B passes: One can become a committer on HDFS, MapReduce, or > Common. Commit to to HDFS/MR implies converse, but individual > appointments to Common continue. > A fails, B fails: Committers continue to be appointed individually to > HDFS, MapReduce, and Common. > > In no scheme would commit rights to Common imply commit rights to > either HDFS or MapReduce, I guess. -C >