ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Voting rules
Date Wed, 29 Nov 2000 16:17:20 GMT
At 04:57  29/11/00 +0100, you wrote:
>When the vetoer becomes convinced that his reasons have been
>invalidated by the requesters counter-arguments, he can
>easily change his vote to 0 or +1, so there is no need
>for an 'automatic' change of the vote.

Well the problem occurs when someone will not argue their position and give
reasons for their convictions. If they don't do that then it is impossible
for the requester to respond to problems because they are not aware of them.

>So the interesting question is: what happens if the vetoer 
>is not convinced by the requesters counter-arguments? 
>Who should decide if the counter-arguments *really* have 
>addressed all issues? 
>This question has four possible answers:
>- the process continues without decision

one way.

>- a third party decides
>- the requesters position wins
>- the vetoers position wins

the other way.

>Letting the process continue means a de facto rejection
>of the change (if the vetoer doesn't change his mind), 
>because the requester can't proceed to commit the change 
>(I assume that the voting process takes place before the 
>change is done). 

depends - it is a lazy veto because it occured after the fact. Anyone can
always -1 a change post it being changed.

>That means that the first answer leads 
>to the same result as the last: the vetoer wins.


>Your position seems to be a combination of answer one and 
>three: as long as the vetoer responds, the process 
>continues; if he stops responding, the requester wins. 

If the vetoer has all his problems solved by counters of requester and the
vetoer does not come up with new reasons to -1 then he is -1 without an
explanation (which is invalid and uncounted).

>So there is only one choice left:
>the vetoer wins. Only the vetoer can recast his vote if he 
>becomes convinced by requesters counter-arguments. Otherwise 
>the change remains rejected.


>Now let's take a look at the idea to put an obligation
>to answer on the vetoer. It doesn't really help the 
>requester to put such an obligation into the rules, 
>because a good will vetoer will always listen to the 
>requester's arguments while a bad will vetoer will 
>always produce some answer to comply with the rule.

I haven't seen many of this type of behaviour at Apache. Almost everyone
that I have encountered will at least consider other positions (in most

>Another disadvantage is that the requester could try 
>producing more and more reasons, until the vetoer becomes 
>too tired to respond.

One way ;)

>(after rereading this paragraph I'd like to emphasize that I 
>don't think this is happening in the jar file discussion).
>My last argument against such an obligation is that it
>would have to become a very complicated rule to be
>fair to both parties (how many days may the vetoer wait 
>until he responds, what happens if he gets on holiday, ...).

;) You should see some of the discussions on other lists. Ant is relatively
tame - it took me about 3 months at one time to convince the other
committers not to veto something (and I needed to convinve them all as
their was only 3 other active committers). While this is painful if you
need a quick fix it generally produces a better product .... eventually. I
ended up just forking for those 3 months and then merging at end.

It also depends on the group. Some of them (Cocoon and Avalon in
particular) tend to do things the "right" way and will take forever to
arrive at a decision. You will notice that some issue keep being brought up
to. If a committer really wants X they will cyclically ask about it until
it get accepted or peeps get really annoyed with them ;)

>Note that this is trying to be a theoretical discussion of 
>the rules. I don't have any opinion on the jar file issue.




| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message