incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: veto stuff
Date Thu, 07 Nov 2002 08:07:40 GMT

Ted Husted wrote:
> I agree with Steve in that the assertions that a "veto cannot be 
> overruled" and a "veto must be justified" are contradictory. The 
> implication is that a unjustified veto is void, but who decides it 
> is void? And in deciding a veto is void, is it not being 
> overruled? 

I've seen this happen too (unfortunately).
Apart from the fact that when we get to veto contention it's already too 
late and something is broken, we still need to have more explicit rules 
to unblock the situation.

> IMHO, the original httpd practices are based on the precept that 
> all Committers are sane and reasonable. In general, I think that's 
> a fair presumption to make about Apache Committers. =:0) However, 
> realisically, the current wording can lead to gridlock when the 
> Committers are not quite as sane or quite as reasonable as those 
> found on httpd. =:0)

IMHHHO, what happened between Peter and Stephen has been in large part a 
massive misunderstanding, of their respective actions and what they 
think about code ownership.
I'll not speak for them though, it's just that I felt the pain of both 
during this thing, it was not fun for both of them and for any of us :-(

> Within Jakarta, one response to a disputed veto is a whiteboard 
> revolution. A Committer can fork the code and let Darwin decide. 
> If the Community follows the fork, eventually it can be made the 
> head.

As in Tomcat.
It did create tensions though, and most of the time it's a drastic 
solution to a what is percieved as an important problem to solve.

> Of course, relying on revolution to resolve voting disputes seems 
> drastic. 

Ah, ok, you said "drastic" too ;-)

> The simplest thing might be language that specifies a 
> veto is subject to a second, a majority vote, or even a super-
> majority vote (like overriding a Presidential veto in the United 
> States).

Something like this could help.

Alternative food for thought:

0) any vetoed commit must be reverted immediately till the issue is not 

1) a veto can be formally challenged not before two weeks(?) after it is 
cast; this prevents from challenging as a norm.

2) when a veto is challenged, someone must back who did the veto with 
his own explanation of why it stands technically (not necessarily why he 
agrees); if not (time?) then it's null.

2-b) before 3) the vetoer or the challenger can revoke their issue with 
no action taken.

3) else, if it still stands, a majority vote can be taken to decide if 
it should stand.

4) if the vote is positive, the veto stands and the challenger loses the 
right to vote for a month or so.
If he lost three challenges in the last 5 months, he looses commit status.

5) if the vote is negative, the veto is removed and the vetoer is in the 
same situation of the challenger as in point 4.

> For the purposes of the Incubator, we might even be able to 
> enumerate several approaches to veto resolution, and each Project 
> can decide for themselves. (An "extension point", if you will.)

I agree, it would show us by evolution which method works better.
I would still keep as a common measure in any case: the majorty of the 
PMC can kick both out of the project if the issue takes longer than some 
defined time to be resolved.

Just random thoughts...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message