httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <c...@hyperreal.org>
Subject cvs commit: apache-devsite voting.html
Date Tue, 26 Aug 1997 14:02:38 GMT
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 (new-httpd@apache.org).
  +  <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>&#177;0</B></DT>
  +  <DT><STRONG>&#177;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 &quot;lazy&quot; voting
  +mode.  This is essentially identical to the
  +<A
  + HREF="#patchvote"
  +>formal voting process</A>,
  +except that &quot;silence gives assent&quot; -- if 48 hours pass without
  +a veto, a quorum of &quot;aye&quot; 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>     
  
  
  

Mime
View raw message