httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject Re: cvs commit: apache-1.3 STATUS
Date Tue, 07 Apr 1998 17:48:54 GMT
On Tue, 7 Apr 1998, Paul Sutton wrote:
> This veto, though, makes me much more concerned. No explanation or
> rational has been posted to new-httpd to allow for discussion (at least,
> as far as I can see at the moment). It also vetos a change for one problem
> -- the symbol hiding problem -- because it does not match your preferred
> naming scheme for another issue -- that this, the API function names.

Actually I partially rescind my annoyance at this veto. I'm not happy with
the way that Jim's previous veto was removed. I would however like to
think that that was due to a mistake or omission during the reformatting
of the votes, rather than a deliberate silent revoking of a vote. 

Anyway, moving forward, the problem now with this situation is that the
two veots (HIDE and ap_) effectively create a stalemate situation. The
former means we have to rename symbols. So everyone votes for their
favourites and ap_* wins. But the second veto prevents that vote from
being implemented. What now? 

I think we need someone to rework the voting procedure so that displeasure
with a proposal can be indicated without invoking the veto. For example,
with the ap_, apapi_ choice, it is possible to +1 your preference. But if
you are against a proposal you cannot give a vote with equal but opposite
waiting, since -1 means veto. I think vote should have four responses:

  +1   -- one vote in favour
  +0   -- no opinion for or against
  -1   -- one vote agains
  VETO -- a veto [not allowed for all votes, see below]

In this case, we should be voting on the prefix. After the results are in
add up the results (-1's cancelling +1's), then choose the most prefered
solution. Sure this does not necessarily cope with complex multi-way
votes, but they can be dealt by creating vote questions appropriately. 

VETO itself should not be an allowed vote when choosing between solutions. 
So for the vote between ap_, apx_, apiint_, etc, the VETO cannot be used
against one (or more) solutions to ensure that only the veto'ers prefered
solution can be chosed. However the option still remains to VETO the
proposed change as a whole if the veto'er considers that the selected
prefered change is not in the interested of the Apache project. 


View raw message