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 > >
