ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Majority and vetos
Date Sun, 21 Jul 2002 03:13:10 GMT

I think different people have different understanding on the 
meaning of 'veto' - and what is decided by community using 
majority and what can be decided by one commiter by using the
veto power.

Product changes can be vetoed. Long term plans, features, ideas,
releases cannot be vetoed - AFAIK.

You can veto a product change as long as you provide:
- reasonable justification ( and at least another commiter must 
'validate', even if he doesn't agree, that the reasons are valid )
- alternative implementation or solution for the problem

What gets included in a release, or when a release happen - that's 
a majority vote. Adding or deprecating features is IMHO a majority

In any case, the 'revolution' allows any idea/feature to be 
implemented in the proposal area and be proposed to the main
tree. A majority will get it in the main branch.

So I don't think someone can 'veto' on 'make all tasks runnable'.

If a vote is proposed and this gets a majority - this feature
will be part of ant ( I don't think this even requires a 
'revolution' ).

You can veto a particular _implementation_ of this - as long
as you have an alternate solution that is better, and 

I see many people who are confused by this - and this is a very 
clear example. 
As long as a proposal is made and the majority aproves it - the only
thing you can veto is the implementation, and you must propose 
a better alternative. 

In the worst case, a revolution can be made and proposed - again
by majority vote, and that will get a particular implementation
into the main tree ( and it can't be vetoed ).

At least that's my understanding - if you think I'm wrong please
say so.

Please stop using the term 'veto' when all it means is 'I don't 
agree with a particular idea'. 


On Sun, 21 Jul 2002, Peter Donald wrote:

> On Saturday 20 July 2002 19:18, Nicola Ken Barozzi wrote:
> > The fact is that we need to be able to run *any* task at init.
> > There are two options:
> >
> > 1) make all tasks runnable top-level
> > 2) deprecate using top-level tasks and add an <init> tag
> >
> > I favor 2, also because 1 vas vetoed I guess, 
> Actually both hvae been vetoed, different egos ;)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message