httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@engelschall.com (Ralf S. Engelschall)
Subject Re: Voting guidelines..
Date Sat, 12 Apr 1997 17:47:25 GMT

In article <97041208593013@decus.org> you wrote:

>     One thing I'm suddenly not clear about.  (Well, that's all I';m
>     going to bring up *now*.. :-)  I'm still quite new here, so maybe
>     I'm missing some subtleties.

Good questions, I'm interested in answers, too. 
I would answer them as follows:

>     Concerning voting: Three +1s are needed to commit; does the
>     submittor count?  I didn't used to think so, but I've noticed
>     recently that maybe only *two* additional votes are needed.  At
>     least that's a practice I've been seeing.

I think the submittor does not count. But three +1 are usually too much for
practice (this is the reason why most of the time a maximum of just 2 others
are used).  The voting rules should changed this way: "There have to be a
minimum of 2 different members who vote with +1 and which are both different
from the submittor".

But this brings up another question I still asked a while ago: The old Apache
Group members always say that everyone can vote and all have equal rights.
Fine, because a democratic way. But not fine when one submits a bad patch and
two of the loosly-coupled members say +1. Then the patch gets commited
according to the rules and before one of the more sophisticated hackers can
vote -1. I think the source should be split into logical parts and each part
should get a primary maintainer. When a change happens to this part, the rules
need also a +1 of the primary maintainer. This way we can be sure that always
one of the guys who really know the code is one of the voters.

>     Also concerning voting: How long a delay is supposed to pass between
>     achievement of a quorum and commission of the change?

Good question. When the delay is too short there is a chance that there are
commits which actually would receive a -1 from one the old hackers.  But if
the delay is too long, it slows down the development process dramatically
(because if too commits are waiting one had to either prevent one from
changing this part of the code or later have to do a merge).

In practice I think 4 days are practical, because this way one can away over
the weekend and still have a change for voting.  And it is shorter than one
working week. So the delay is acceptable for active development.

>     And finally: What happens if a veto appears after a change has been
>     committed?

Hmmmmmm.... when we are follow the rules in a strict way we have to remove the
patch. This is not really difficult with CVS. I think is ok this way, but one
need a maximum time, i.e.  when a -1 occurs in the next following 4 days after
the commit, the code is totally removed. After that period the "-1"-voter
should better submit a new real patch which do the job better. This new
patch should be again voted, of course.

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message