Return-Path: Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list general@incubator.apache.org Received: (qmail 52847 invoked from network); 7 Nov 2002 08:08:41 -0000 Received: from fep01.tuttopmi.it (HELO fep01-svc.flexmail.it) (212.131.248.100) by daedalus.apache.org with SMTP; 7 Nov 2002 08:08:41 -0000 Received: from apache.org ([80.204.154.181]) by fep01-svc.flexmail.it (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021107080849.DCNX27147.fep01-svc.flexmail.it@apache.org> for ; Thu, 7 Nov 2002 09:08:49 +0100 Message-ID: <3DCA1F4C.8010109@apache.org> Date: Thu, 07 Nov 2002 09:07:40 +0100 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: general@incubator.apache.org Subject: Re: veto stuff References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 resolved 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 nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------