OK - sorry for misunderstanding you. It appears we are in agreement and my use of "majority" in that sentence is incorrect. The wording I quoted from the httpd page is much clearer (at least 3 +1 votes and no vetoes).
Ralph On Oct 13, 2013, at 6:20 PM, Ted Dunning wrote: > Ralph, > > I completely agree that this vote wasn't consensus. > > But where you say > > As I understand this, consensus means that a majority must vote and there >> must not be any -1 votes among those who voted. > > > I disagree. The only quorum typically required for ASF consensus votes is > 3 +1's, not a majority of possible voters. > > > > > On Mon, Oct 14, 2013 at 2:15 AM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> Please re-read my message. James stated " We definitely have enough people >> voting to be considered a consensus (consensus != unanimous)." My point >> was to quote what Roy posted a few days ago that said while consensus isn't >> unanimous it also isn't the simple majority vote either, so to state that >> consensus was reached is incorrect because there were several -1 votes. >> >> Ralph >> >> On Oct 13, 2013, at 3:51 PM, Ted Dunning wrote: >> >>> 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-1e40d6916...@gmail.com%3E >>> >>> >> http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3c08688247-b00e-44c7-8b21-f107921b4...@gmail.com%3E >>> >>> >> http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3c5256ff12.3070...@gmail.com%3E >>> >>> >> http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3c110b24a9-dd67-436d-9e2d-e29521693...@gmail.com%3E >>> >>> >> http://mail-archives.apache.org/mod_mbox/commons-dev/201310.mbox/%3c110b24a9-dd67-436d-9e2d-e29521693...@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 < >> ralph.go...@dslextreme.com>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%3Efromwhich >> 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 <phil.ste...@gmail.com> >>>> 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 <brit...@apache.org >>> >>>> wrote: >>>>>>>> 2013/10/11 Oliver Heger <oliver.he...@oliver-heger.de> >>>>>>>> >>>>>>>>> Am 11.10.2013 02:10, schrieb Phil Steitz: >>>>>>>>>> >>>>>>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy <ol...@apache.org> >>>> 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 < >>>> ja...@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-unsubscr...@commons.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Olivier Lamy >>>>>>>>>>> Ecetera: http://ecetera.com.au >>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>>>>> >>>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>> >>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
