Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 93AB810A0F for ; Sun, 13 Oct 2013 22:52:35 +0000 (UTC) Received: (qmail 44712 invoked by uid 500); 13 Oct 2013 22:52:35 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 44620 invoked by uid 500); 13 Oct 2013 22:52:35 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 44612 invoked by uid 99); 13 Oct 2013 22:52:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Oct 2013 22:52:35 +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 (nike.apache.org: domain of ted.dunning@gmail.com designates 209.85.223.172 as permitted sender) Received: from [209.85.223.172] (HELO mail-ie0-f172.google.com) (209.85.223.172) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Oct 2013 22:52:28 +0000 Received: by mail-ie0-f172.google.com with SMTP id x13so13200877ief.31 for ; Sun, 13 Oct 2013 15:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=fqG5jQGL+WDC/cKL3aCIWu/5MktKep4cwfaCJnuPMEA=; b=0ewBa6Mntf/Q8ov9gw7nrbw3JryPDPWmTGK/LxPGtbKbR/uhX39eS+oxbSc88oikn6 LwnZkvx5VjvJAhhXss4P722+CLWCFjSHVTV1rMxnnvfbn2y/PWwF99G2NqLNZIkp2brA VBtH52v4POzyzAuB/pqHjUyinAg3hfw5dh53BQuqUilMI3EOy7qKKB55hEXSU81PAvm6 vQ+cVmgx/uURejB90h+mUl8V25ATUtlNqHSRD9Sa/Q9Yj7tL4W2IK8SnETAz9cdYVUrn VbKAzlFI2lbdfDgxGzJaDGnx3HihLHqKKVEmr2/TQnKbXK8FoYi0EvRhDYlxK7s5nnhl /57Q== X-Received: by 10.50.118.105 with SMTP id kl9mr10868420igb.3.1381704727362; Sun, 13 Oct 2013 15:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.224.145 with HTTP; Sun, 13 Oct 2013 15:51:37 -0700 (PDT) In-Reply-To: <73103108-8C0E-4909-B1ED-89BAFC17ED18@dslextreme.com> References: <110B24A9-DD67-436D-9E2D-E29521693809@gmail.com> <5258521D.2090401@oliver-heger.de> <525AF8EB.3030708@gmail.com> <73103108-8C0E-4909-B1ED-89BAFC17ED18@dslextreme.com> From: Ted Dunning Date: Sun, 13 Oct 2013 23:51:37 +0100 Message-ID: Subject: Re: [VOTE] Move Apache Commons to Git for SCM... - is not a consensus To: Commons Developers List Content-Type: multipart/alternative; boundary=089e011769cf759b4504e8a7331b X-Virus-Checked: Checked by ClamAV on apache.org --089e011769cf759b4504e8a7331b Content-Type: text/plain; charset=UTF-8 Ralph, Majority votes at ASF almost never require a majority of all possible voters. Almost always the (plus > 3 && plus > minus) convention is used. As you can find in innumerable threads as well, consensus among the discussion participants is preferable for big changes (like moving to git). Consensus does not depend on the potential number of voters. In fact, virtually nothing depends on a quorum at ASF other than member votes. That said, this vote may well a small victory that causes a larger problem. The hard question here is whether it is better to pause here in order to make faster progress. Phil's point is a bit out of order ... if he had responded to the request for votes with his statement that the vote was premature, it would have been much better. To wait until after the vote has been lost and then claim that more discussion is needed is a bit of a problem, at least from the point of view of appearance. One very confusing procedural point is that half-way through the vote, the subject line reverted to [DISCUSS] rather than [VOTE]. See http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3CCALznzY4v1bPGrMotJkmSN8wp9hSjs8mMjSj89wfzBEgimhtxrw%40mail.gmail.com%3E This is the point that Phil first commented. On the other hand, Phil also commented on the thread with the [VOTE] subject a number of times: http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3CA9D202A4-6E76-42D8-9606-1E40D69162C7@gmail.com%3E http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3C08688247-B00E-44C7-8B21-F107921B49D1@gmail.com%3E http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3C5256FF12.3070806@gmail.com%3E http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3C110B24A9-DD67-436D-9E2D-E29521693809@gmail.com%3E http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3C110B24A9-DD67-436D-9E2D-E29521693809@gmail.com%3E In none of these did he say that the vote was premature. On Sun, Oct 13, 2013 at 11:11 PM, Ralph Goers wrote: > Actually, if you read Roy's post from a few days ago on Incubator General > you will find that consensus is != to majority or unanimity. See > http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/ajax/%3CC2FDB244-459D-4EC4-954A-7A7F6C4B179B%40gbiv.com%3Efrom which I quote below: > > "Consensus is that everyone who shares an opinion agrees to a common > resolution (even if they do not personally prefer that resolution). > Unanimity means that everyone present agrees (for a PMC discussing things > in email, that means everyone listed on the roster must affirmatively > agree). > > Hence, consensus decisions can be vetoed, as is clearly stated in the HTTP > Server Project Guidelines, unless the project has decided to adopt some > other set of bylaws." > As I understand this, consensus means that a majority must vote and there > must not be any -1 votes among those who voted. Unanimity means everyone > must vote and no one must vote -1. Of course, majority means there must be > at least three +1 votes and more +1s than -1s. > > Notice that http://httpd.apache.org/dev/guidelines.html specifically says > "An action item requiring consensus approval must receive at least 3 > binding +1 votes and no vetoes.", However, I don't see any guidance on the > httpd page that would indicate whether this vote requires a consensus or a > majority. One could certainly argue that deciding to move from svn to git > is "procedural" and thus only requires a majority, however I tend to > believe that consensus would be what would be preferred for this vote. > > Ralph > > > On Oct 13, 2013, at 1:52 PM, James Carman wrote: > > > Phil, > > > > While I appreciate your concerns, the vote is a valid vote: > > > > "Votes on procedural issues follow the common format of majority rule > > unless otherwise stated. That is, if there are more favourable votes > > than unfavourable ones, the issue is considered to have passed -- > > regardless of the number of votes in each category. (If the number of > > votes seems too small to be representative of a community consensus, > > the issue is typically not pursued. However, see the description of > > lazy consensus for a modifying factor.)" > > > > I got this information from: > > > > http://www.apache.org/foundation/voting.html > > > > We definitely have enough people voting to be considered a consensus > > (consensus != unanimous). > > > > However, we will not move forward with the Git move if we don't have > > any luck with our test component (different thread). If we see the > > test component isn't working out well, then we can just decide (or > > vote again) to scrap the idea and move on. Hopefully that addresses > > your concerns. > > > > Thanks, > > > > James > > > > On Sun, Oct 13, 2013 at 3:47 PM, Phil Steitz > wrote: > >> On 10/13/13 8:09 AM, James Carman wrote: > >>> Well, it has been 72 hours, so let's tally up the votes. As I see it > >>> (counting votes on both lists): > >>> > >>> +1s > >>> James Carman > >>> Romain Manni-Bucau > >>> Matt Benson > >>> Benedikt Ritter > >>> Bruno Kinoshita > >>> Gary Gregory > >>> Luc Maisonobe > >>> Oliver Heger > >>> Christian Grobmeier > >>> Torsten Curdt > >>> > >>> -1s > >>> Mark Thomas > >>> Thomas Vandahl > >>> Damjan Jovanovic > >>> Gilles Sadowski > >>> Jorg Schaible > >>> > >>> +0.5 > >>> Olivier Lamy > >>> > >>> +0 > >>> Ralph Goers > >>> > >>> -0 > >>> Emmanuel Bourg > >>> > >>> The vote passes, so Apache Commons will be moving to Git for SCM. We > >>> should begin working on a plan. I propose we set up a wiki page for > >>> that. > >> > >> I protest. It is fine for some components to experiment, but if we > >> are going to force all to move, we really need consensus and that is > >> clearly not the case here. I did not vote as I frankly saw the VOTE > >> as premature. We should use VOTEs as a last resort, not a first > >> step or way to avoid getting to consensus on non-release issues. > >> > >> Phil > >>> > >>> Please let me know if I have missed anyone's vote. Having two vote > >>> threads (my fault) caused a bit of confusion, but I think I got > >>> everyone's vote. > >>> > >>> Thank you, > >>> > >>> James > >>> > >>> On Fri, Oct 11, 2013 at 4:01 PM, Benedikt Ritter > wrote: > >>>> 2013/10/11 Oliver Heger > >>>> > >>>>> Am 11.10.2013 02:10, schrieb Phil Steitz: > >>>>>> > >>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy > wrote: > >>>>>>> > >>>>>>> Even I like git and use it daily, I will vote +0,5. > >>>>>>> > >>>>>>> Why other apache projects need to have their own commons-csv > >>>>>>> repackaged release? why tomcat need to use a svn:external on dbcp > >>>>>>> instead of a released version? why servicemix need to repackage all > >>>>>>> commons jar to have proper osgi bundles? > >>>>>>> > >>>>>>> I simply believe moving to git won't fix those problems about the > too > >>>>>>> complicated release process which scare folks here to try > releasing a > >>>>>>> component!! > >>>>>>> So no release happen at the end.... > >>>>>>> > >>>>>> I agree that the release process is certainly a problem; but the big > >>>>> problem IMO is just too many components for too few really active > >>>>> committers. Once we actually have something ready to release, we > have > >>>>> generally been able to fumble our way through the process. The > problem is > >>>>> getting there. > >>>>>> I think the best thing we can do is focus on getting some things > ready > >>>>> for release. I will help on pool, DBCP, math. I won't rob Mark of > the > >>>>> oppty to rm pool2, but will help ;). All are welcome to join the fun > >>>>> cleaning up the docs and other loose ends on that and then dbcp2. > >>>>>> Who wants to step up to drive some other things to release? > >>>>> I plan to prepare a release of BeanUtils soon. > >>>>> > >>>> Good to hear. There is a lot to do. I started generification a while > back. > >>>> If you like you can join #asfcommons and we can have a talk about BU. > >>>> > >>>> Benedikt > >>>> > >>>> > >>>>> Oliver > >>>>> > >>>>>> Phil > >>>>>>>> On 11 October 2013 01:50, James Carman < > james@carmanconsulting.com> > >>>>> wrote: > >>>>>>>> All, > >>>>>>>> > >>>>>>>> We have had some great discussions about moving our SCM to Git. I > >>>>>>>> think it's time to put it to a vote. So, here we go: > >>>>>>>> > >>>>>>>> +1 - yes, move to Git > >>>>>>>> -1 - no, do not move to Git > >>>>>>>> > >>>>>>>> The vote will be left open for 72 hours. Go! > >>>>>>>> > >>>>>>>> > --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Olivier Lamy > >>>>>>> Ecetera: http://ecetera.com.au > >>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org > >>>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > >>>>>> For additional commands, e-mail: dev-help@commons.apache.org > >>>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > >>>>> For additional commands, e-mail: dev-help@commons.apache.org > >>>>> > >>>>> > >>>> > >>>> -- > >>>> http://people.apache.org/~britter/ > >>>> http://www.systemoutprintln.de/ > >>>> http://twitter.com/BenediktRitter > >>>> http://github.com/britter > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > >>> For additional commands, e-mail: dev-help@commons.apache.org > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > >> For additional commands, e-mail: dev-help@commons.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > > For additional commands, e-mail: dev-help@commons.apache.org > > > > --089e011769cf759b4504e8a7331b--