coar 97/08/26 07:02:37
Modified: . voting.html
Log:
Do a little minor cleanup and add note about so-called
"lazy voting".
Revision Changes Path
1.3 +99 -51 apache-devsite/voting.html
Index: voting.html
===================================================================
RCS file: /export/home/cvs/apache-devsite/voting.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- voting.html 1997/07/26 11:57:02 1.2
+++ voting.html 1997/08/26 14:02:36 1.3
@@ -2,36 +2,51 @@
<HEAD>
<TITLE>Apache voting rules and guidelines</TITLE>
</HEAD>
-<BODY>
+<!-- Background white, links blue (unvisited), navy (visited), red (active)
-->
+ <BODY
+ BGCOLOR="#FFFFFF"
+ TEXT="#000000"
+ LINK="#0000FF"
+ VLINK="#000080"
+ ALINK="#FF0000"
+ >
+
+<H1 ALIGN=CENTER>
+ <IMG SRC="images/apache_logo.gif" ALT=""><BR>
+ Apache voting rules and guidelines
+</H1>
-<H1 ALIGN=CENTER><IMG SRC="images/apache_logo.gif" ALT=""><BR><BR>
-Apache voting rules and guidelines</H1>
-
-<P>This document defines the rules and guidelines for Apache Group members
+<P>
+This document defines the rules and guidelines for Apache Group members
to follow when voting on patches, documentation, or other action items
-to be applied to the Apache HTTP Server.</P>
+to be applied to the Apache HTTP Server.
+</P>
-<P>The objective here is to avoid unnecessary conflict over changes and
+<P>
+The objective here is to avoid unnecessary conflict over changes and
continue to produce a quality system in a timely manner. Not all conflict
can be avoided, but at least we can agree on the procedures for conflict
-to be resolved.</P>
+to be resolved.
+</P>
-<P>Some abbreviations used below...</P>
+<P>
+Some abbreviations used below...
+</P>
<DL>
- <DT><B>mailing list</B></DT>
- <DD>The Apache developers' mailing list ([email protected]).
+ <DT><STRONG>mailing list</STRONG></DT>
+ <DD>The Apache developers' mailing list.
Subscription to the list is by invitation only, and only subscribers
can post directly to the list.</DD>
- <DT><B>CURRENT</B></DT>
+ <DT><STRONG>CURRENT</STRONG></DT>
<DD>The most recent version of the source. Used as
the base code into which new patches are to be merged.</DD>
- <DT><B>C_VERSION</B></DT>
- <DD>The version number of <B>CURRENT</B>.</DD>
+ <DT><STRONG>C_VERSION</STRONG></DT>
+ <DD>The version number of <STRONG>CURRENT</STRONG>.</DD>
- <DT><B>NEXT</B></DT>
+ <DT><STRONG>NEXT</STRONG></DT>
<DD>The next version of the source. The product of
- applying approved patches to <B>CURRENT</B></DD>
+ applying approved patches to <STRONG>CURRENT</STRONG></DD>
</DL>
@@ -49,14 +64,14 @@
<H3>Types of Action Items</H3>
<DL>
- <DT><B>Code Changes</B></DT>
+ <DT><STRONG>Code Changes</STRONG></DT>
<DD>Code changes require peer review and testing over a wide range
of server platforms. Therefore, all code changes must pass through
a formal "patch vote", as described <a href="#patchvote">below</A>.
All those participating in a patch vote must be willing and able
to test the patched system.</DD>
- <DT><B>Documentation Changes</B></DT>
+ <DT><STRONG>Documentation Changes</STRONG></DT>
<DD>Documentation changes are only voted on after (or during) the change.
The author of the changes must notify the mailing list, preferably
in advance of the work to avoid duplicate efforts, of where the
@@ -68,7 +83,7 @@
the veto once the problem has been corrected (this may be assumed
in good faith).</DD>
- <DT><B>Long Term Plans</B></DT>
+ <DT><STRONG>Long Term Plans</STRONG></DT>
<DD>Long term plans are simply announcements that group members
are working on particular issues related to the Apache software.
These are not voted on,
@@ -90,17 +105,17 @@
<P>Each vote can be made in one of three flavors:
<DL COMPACT>
- <DT><B>+1</B></DT>
+ <DT><STRONG>+1</STRONG></DT>
<DD> Yes, agree, or the action should be performed. On some issues, this
vote must only be given after the voter has tested the action on
their own system(s).
</DD><P>
- <DT><B>±0</B></DT>
+ <DT><STRONG>±0</STRONG></DT>
<DD> Abstain, no opinion, or I am happy to let the other group members
decide this issue. An abstention may have detrimental affects if
too many people abstain.
</DD><P>
- <DT><B>-1</B></DT>
+ <DT><STRONG>-1</STRONG></DT>
<DD> No, I <strong>veto</strong> this action. All vetos must include
an explanation of why the veto is appropriate. A veto with
no explanation is void.
@@ -112,12 +127,16 @@
<H2><IMG SRC="images/apache_feather_bullet.gif" alt="o ">
<A NAME="patchvote">Formal Patch Votes</A></H2>
-
+<P>
As mentioned above, changes to the source code require peer review
and adequate testing across many platforms. The formal patch vote
rules are intended to ensure that this happens even when we are all in a
-hurry to see things fixed.
-
+hurry to see things fixed. However, also see the section on
+<A
+ HREF="#lazy-voting"
+>lazy voting</A>
+mode.
+</P>
<P>There are four distinct roles in the patch vote process, each of which
may be shared by multiple group members: patch provider, vote coordinator,
voter, and version builder.
@@ -131,14 +150,14 @@
<H3>Uploading an Action Item</H3>
<P>Action items (usually patches) are uploaded to hyperreal (apache.org)
-via FTP, either directly into the directory for patches to <B>CURRENT</B>
-(/httpd/patches/for_Apache_<B>C_VERSION</B>/), or into an incoming
+via FTP, either directly into the directory for patches to
<STRONG>CURRENT</STRONG>
+(/httpd/patches/for_Apache_<STRONG>C_VERSION</STRONG>/), or into an incoming
FTP directory for later transfer into the patch directory.</LI><P>
<P>Each filename should at least hint at the action objective and
include reference to:
<OL>
- <LI>(C_VERSION) the version number of <B>CURRENT</B></LI>
+ <LI>(C_VERSION) the version number of <STRONG>CURRENT</STRONG></LI>
<LI>(ID) the unique action item numeric ID</LI>
<LI>(p) the patch letter, if an alternate patchfile is proposed</LI>
</OL>
@@ -150,7 +169,7 @@
if the action item is not (yet) in the form of a patch.
<P>The syntax for filenames containing patches is:
-<PRE> IDp.description.<B>C_VERSION</B>.patch</PRE>
+<PRE> IDp.description.<STRONG>C_VERSION</STRONG>.patch</PRE>
e.g., <BR>
<PRE> 01.ScriptAliasKaboom.0.8.11.patch
01a.ScriptAliasKaboom.0.8.11.patch
@@ -165,18 +184,18 @@
(formatted like e-mail or HTTP headers):
<DL>
- <DT><B>From:</B></DT>
+ <DT><STRONG>From:</STRONG></DT>
<DD>A list of patch authors and/or people who identified the problem.
- <DT><B>Subject:</B></DT>
+ <DT><STRONG>Subject:</STRONG></DT>
<DD>A description of the problem being addressed.
- <DT><B>Requires:</B></DT>
+ <DT><STRONG>Requires:</STRONG></DT>
<DD>A list of other patches that must be applied before this one.
- <DT><B>Affects:</B></DT>
+ <DT><STRONG>Affects:</STRONG></DT>
<DD>A list of source file names that this patch affects
- <DT><B>Changelog:</B></DT>
+ <DT><STRONG>Changelog:</STRONG></DT>
<DD>A couple of lines for use in a future changelog, so that the
patch (if accepted) can be recorded.
- <DT><B>Comments:</B></DT>
+ <DT><STRONG>Comments:</STRONG></DT>
<DD>Any additional comments about the problem.
</DL>
@@ -185,7 +204,7 @@
<H3>Patch Format</H3>
<P>The patch should be created by using <CODE>diff -C3</CODE> on the
-<B>CURRENT</B> source and the modified source. E.g.,</P>
+<STRONG>CURRENT</STRONG> source and the modified source. E.g.,</P>
<PRE> diff -C3 http_main.c.orig http_main.c</PRE>
@@ -221,7 +240,7 @@
garner their own votes -- they do not automatically inherit the votes
for patches they replace.</P>
-<P>Patches for <B>CURRENT</B> can be uploaded at any time before or
+<P>Patches for <STRONG>CURRENT</STRONG> can be uploaded at any time before or
during a voting session.</P>
<H3>The Voting Session</H3>
@@ -231,7 +250,7 @@
<UL>
<LI>be the vote coordinator: collect the votes cast by group members</LI>
<LI>be the version builder: apply approved patches to create the
- <B>NEXT</B> version of the system.</LI>
+ <STRONG>NEXT</STRONG> version of the system.</LI>
</UL>
<P>The person or persons volunteering to perform these tasks agree
@@ -252,15 +271,15 @@
<P>Votes are cast as follows;
<DL COMPACT>
- <DT><B>+1</B></DT>
+ <DT><STRONG>+1</STRONG></DT>
<DD> can be given to a patch if the person has,
<OL>
<LI>read the patch header to see what problem it addresses</LI>
- <LI>successfully patched it into <B>CURRENT</B></LI>
+ <LI>successfully patched it into <STRONG>CURRENT</STRONG></LI>
<LI>observed no bad side-effects resulting from the patch.</LI>
</OL>
</DD><P>
- <DT><B>-1</B></DT>
+ <DT><STRONG>-1</STRONG></DT>
<DD> is a veto on the patch. All vetos must come
with an explanation of why the veto is appropriate. A veto with
no explanation is void.
@@ -279,10 +298,10 @@
vote deadline has passed. The results of the vote are then posted
to the mailing list.</P>
-<P><B>In order to be approved, an action item file must receive
-at least 3 positive votes and NO vetos.</B></P>
+<P><STRONG>In order to be approved, an action item file must receive
+at least 3 positive votes and NO vetos.</STRONG></P>
-<P>Late <B>+1</B> votes can be ignored or accepted by the vote coordinator
+<P>Late <STRONG>+1</STRONG> votes can be ignored or accepted by the vote
coordinator
at his/her discretion. A late veto has no value: It can only be used
to try to convince positive voters to rethink. If a positive voter changes
to a veto, that veto is valid even though it is late.</P>
@@ -290,12 +309,12 @@
<H3>Release Build and Announcement</H3>
<P>After the vote coordinator gives the version builder the results,
-<B>NEXT</B> is created by applying the approved patches
-to <B>CURRENT</B>, making the changes called for by other approved
+<STRONG>NEXT</STRONG> is created by applying the approved patches
+to <STRONG>CURRENT</STRONG>, making the changes called for by other approved
(non-patch) action items, adding the approved action item descriptions
to the changelog, and incrementing the version number.</P>
-<P><B>NEXT</B> is then uploaded by the version builder to hyperreal
+<P><STRONG>NEXT</STRONG> is then uploaded by the version builder to hyperreal
and placed in the pre-release directory (/httpd/dist) in compressed
and gzip'd tar files that name the new version number. The availability
of the new version is then announced on the private mailing list.</P>
@@ -303,18 +322,18 @@
<P>After the version announcement, accidental mistakes made by the builder
can be rectified without a vote, but must be announced to the group.</P>
-<P>Unless stated otherwise at the start of the vote session, <B>NEXT</B>
+<P>Unless stated otherwise at the start of the vote session,
<STRONG>NEXT</STRONG>
is assumed to be intended for public release. If an objection to the
public release is put forward, a majority decision vote will determine
whether or not the release is made public. Unlike the other votes,
a minority opinion cannot stop a public release.</P>
-<P>If <B>NEXT</B> is to be released publically, everyone on the mailing
-list should make the effort to download it and try it out. <B>NEXT</B>
+<P>If <STRONG>NEXT</STRONG> is to be released publically, everyone on the
mailing
+list should make the effort to download it and try it out.
<STRONG>NEXT</STRONG>
should not be publically released until 24 hours after it has been created
and announced to the group.</P>
-<P>If one of the patches used to create <B>NEXT</B> is subsequently
+<P>If one of the patches used to create <STRONG>NEXT</STRONG> is subsequently
found to cause a more serious problem than those it fixed, this problem
should be reported to the group and any public release postponed until
a majority decision on how to rectify the problem is obtained.</P>
@@ -338,10 +357,39 @@
after 24hours or three +1 votes are given for the patch, whichever comes
first.</P>
+<H2>
+ <A NAME="lazy-voting">
+ Lazy-Voting Mode
+ </A>
+</H2>
+<P>
+At some times, such as early in the devlopment cycle, it may be
+desirable to operate in what has been called "lazy" voting
+mode. This is essentially identical to the
+<A
+ HREF="#patchvote"
+>formal voting process</A>,
+except that "silence gives assent" -- if 48 hours pass without
+a veto, a quorum of "aye" votes is assumed even not officially
+collected.
+</P>
+<P>
+Formal and lazy voting environments may co-exist; some topics may
+require formal votes whilst others may not. Common sense should be
+exercised, and potentially highly-controversial patches shouldn't
+be submitted under the lazy rules.
+</P>
+<P>
+When a patch submitter expects to take advantage of lazy voting mode, it
+<EM>must</EM> be explicitly stated in the patch submission.
+</P>
<HR SIZE=6>
<ADDRESS>
Rob Hartill and Roy Fielding<BR>
3 September 1995
+</ADDRESS>
+<ADDRESS>
+ Modified 26 August 1997 by Ken Coar
</ADDRESS>
</BODY>
</HTML>
