commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [VOTE] Move Apache Commons to Git for SCM... - is not a consensus
Date Mon, 14 Oct 2013 01:27:15 GMT
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.goers@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-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 <
>> ralph.goers@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.steitz@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 <britter@apache.org
>>> 
>>>> wrote:
>>>>>>>> 2013/10/11 Oliver Heger <oliver.heger@oliver-heger.de>
>>>>>>>> 
>>>>>>>>> Am 11.10.2013 02:10, schrieb Phil Steitz:
>>>>>>>>>> 
>>>>>>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy <olamy@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 <
>>>> 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
>>>>> 
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message