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

Reply via email to