httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: httpd-site/xdocs/dev guidelines.xml guidelines.html
Date Tue, 27 Nov 2001 03:18:30 GMT
jerenkrantz    01/11/26 19:18:30

  Modified:    docs/dev guidelines.html
  Added:       xdocs/dev guidelines.xml
  Removed:     xdocs/dev guidelines.html
  Log:
  Change dev/guidelines.html into XML format.
  
  Revision  Changes    Path
  1.2       +323 -249  httpd-site/docs/dev/guidelines.html
  
  Index: guidelines.html
  ===================================================================
  RCS file: /home/cvs/httpd-site/docs/dev/guidelines.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- guidelines.html	2001/11/21 07:31:46	1.1
  +++ guidelines.html	2001/11/27 03:18:30	1.2
  @@ -1,249 +1,314 @@
  -<HTML>
  -<HEAD>
  -<TITLE>Apache Project Guidelines and Voting Rules</TITLE>
  -</HEAD>
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  - <BODY
  -  BGCOLOR="#FFFFFF"
  -  TEXT="#000000"
  -  LINK="#0000FF"
  -  VLINK="#000080"
  -  ALINK="#FF0000"
  - >
  -
  -<CENTER>
  -<IMG SRC="images/apache_logo.gif" ALT="">
  -<H1 ALIGN=CENTER>Apache Project Guidelines</H1>
  -
  -</CENTER>
  -
  -<P>
  -This document defines the guidelines for the
  -<A HREF="http://dev.apache.org/">Apache Project</A>.
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +               "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  +<html>
  + <head>
  +  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
  +       <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
  +    <title>Apache HTTPD Project Guidelines and Voting Rules - The Apache HTTP Server Project</title>
  + </head>
  + <body bgcolor="#ffffff" text="#000000" link="#525D76">
  +<p><a href="/"><img src="../images/httpd_logo_wide.gif" alt="The Apache HTTP Server Project" border="0"/></a></p>
  + <table border="0" width="100%" cellspacing="4">
  +   <tr>
  +    <!-- LEFT SIDE NAVIGATION -->
  +    <td valign="top" nowrap="nowrap">
  +           <p><b>Essentials</b></p>
  +    <menu compact="compact">
  +          <li><a href="/ABOUT_APACHE.html">About</a></li>
  +          <li><a href="http://www.apache.org/LICENSE.txt">License</a></li>
  +          <li><a href="/docs/misc/FAQ.html">FAQ</a></li>
  +          <li><a href="/security_report.html">Security<br />Reports</a></li>
  +        </menu>
  +      <p><b>Download!</b></p>
  +    <menu compact="compact">
  +          <li><a href="http://www.apache.org/dyn/closer.cgi">from a mirror</a></li>
  +          <li><a href="http://www.apache.org/dist/httpd/">from here</a></li>
  +        </menu>
  +      <p><b><a 
  +href="/docs-project/">Documentation</a></b></p>
  +    <menu compact="compact">
  +          <li><a href="/docs/">Apache 1.3</a></li>
  +          <li><a href="/docs-2.0/">Apache 2.0</a></li>
  +        </menu>
  +      <p><b>Get Involved</b></p>
  +    <menu compact="compact">
  +          <li><a href="/lists.html">Mailing Lists</a></li>
  +          <li><a href="bug_report.html">Bug Reports</a></li>
  +          <li><a href="/dev/">Developer Info</a></li>
  +        </menu>
  +      <p><b>Subprojects</b></p>
  +    <menu compact="compact">
  +          <li><a href="/docs-project/">Docs</a></li>
  +          <li><a href="/test/">Test</a></li>
  +        </menu>
  +      <p><b><a 
  +href="/info/">Miscellaneous</a></b></p>
  +    <menu compact="compact">
  +          <li><a href="/contributors/">Contributors</a></li>
  +          <li><a href="/awards.html">Awards</a></li>
  +          <li><a href="/in_the_news.html">In the News</a></li>
  +          <li><a href="http://nav.webring.yahoo.com/hub?ring=apachesupport&amp;id=12&amp;hub">Support<br />Webring</a></li>
  +        </menu>
  +    </td>
  +    <!-- RIGHT SIDE INFORMATION -->
  +    <td align="left" valign="top">
  +                <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>Apache Project Guidelines</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<p>This document defines the guidelines for the
  +<a href="http://httpd.apache.org/">Apache HTTPD Project</a>.
   It includes definitions of how conflict is resolved by voting,
  -who is able to vote, and the procedures to follow for proposing and making
  -changes to the Apache products.
  -</P>
  -
  -<P>
  -The objective here is to avoid unnecessary conflict over changes and
  +who is able to vote, and the procedures to follow for proposing and 
  +making changes to the Apache products.</p>
  +<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>
  -
  -<H2><IMG SRC="images/apache_feather_bullet.gif" ALT="o ">
  -People, Places, and Things</H2>
  -
  -<DL>
  -  <DT><STRONG>Apache Group</STRONG></DT>
  -  <DD>The group of volunteers who are responsible for managing the
  +to be resolved.</p>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>People, Places, and Things</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<dl>
  +  <dt><strong>Apache Group</strong></dt>
  +  <dd>The group of volunteers who are responsible for managing the
         Apache Project.  This includes deciding what is distributed as
         products of the Apache Project, maintaining the Project's shared
         resources, speaking on behalf of the Apache Project, resolving
         license disputes regarding Apache products, and establishing
         these guidelines.
   
  -      <P>Membership in the Apache Group is by invitation only and must
  +      <p>Membership in the Apache Group is by invitation only and must
         be approved by consensus of the active Apache Group members.
         A member is considered inactive by their own declaration or by not
         contributing in any form to the project for over six months.  An
         inactive member can become active again by reversing whichever condition
  -      made them inactive (<EM>i.e.</EM>, by reversing their earlier
  -      declaration or
  -      by once again contributing toward the project's work).  Membership
  -      can be revoked by a unanimous vote of all the active members other
  -      than the member in question.</DD><P>
  +      made them inactive (<em>i.e.</em>, by reversing their earlier
  +      declaration or by once again contributing toward the project's work).
  +      Membership can be revoked by a unanimous vote of all the active 
  +      members other than the member in question.</p>
  +  </dd>
   
  -  <DT><STRONG>Apache Developers</STRONG></DT>
  -  <DD>All of the volunteers who are contributing time, code, documentation,
  +  <dt><strong>Apache Developers</strong></dt>
  +  <dd>All of the volunteers who are contributing time, code, documentation,
         or resources to the Apache Project.  A developer that makes sustained,
         welcome contributions to the project for over six months is usually
         invited to join the Apache Group, though the exact timing of such
  -      invitations depends on many factors.</DD><P>
  +      invitations depends on many factors.</dd>
   
  -  <DT><STRONG>mailing list</STRONG></DT>
  -  <DD>The Apache developers' primary mailing list for discussion of issues
  -      and changes related to the project (<EM>dev@httpd.apache.org</EM>).
  +  <dt><strong>mailing list</strong></dt>
  +  <dd>The Apache developers' primary mailing list for discussion of issues
  +      and changes related to the project (<em>dev@httpd.apache.org</em>).
         Subscription to the list is open, but only subscribers
  -      can post directly to the list.</DD><P>
  +      can post directly to the list.
  +  </dd>
   
  -  <DT><STRONG>private list</STRONG></DT>
  -  <DD>The Apache Group's private mailing list for discussion of issues
  +  <dt><strong>private list</strong></dt>
  +  <dd>The Apache Group's private mailing list for discussion of issues
         that are inappropriate for public discussion, such as legal, personal,
         or security issues prior to a published fix.  Subscription to the list
  -      is only open to Apache Group members.</DD><P>
  +      is only open to Apache Group members.
  +  </dd>
   
  -  <DT><STRONG>CVS</STRONG></DT>
  -  <DD>All of the Apache products are maintained in shared information
  -      repositories using <A HREF="devnotes">CVS on
  -      <EM>dev.apache.org</EM></A>.  Only some of the Apache developers have
  +  <dt><strong>CVS</strong></dt>
  +  <dd>All of the Apache products are maintained in shared information
  +      repositories using <a href="devnotes.html">CVS on
  +      <em>httpd.apache.org</em></a>.  Only some of the Apache developers have
         write access to these repositories; everyone has read access via
  -      <A HREF="anoncvs">anonymous CVS</A>.  Developers who want write
  +      <a href="anoncvs">anonymous CVS</a>.  Developers who want write
         access need to ask for it on the mailing list and, if approved, need
  -      to ask the admin of <EM>dev.apache.org</EM> for a user account.</DD>
  -
  -</DL>
  -
  -<H2><IMG SRC="images/apache_feather_bullet.gif" ALT="o ">
  -STATUS</H2>
  -
  -<P>
  -Each of the Apache Project's active source code repositories contain a file
  -called "STATUS" which is used to keep track of the agenda and plans for
  -work within that repository.  The STATUS file includes information about
  -release plans, a summary of code changes committed since the last release,
  -a list of proposed changes that are under discussion, brief notes about
  -items that individual developers are working on or want discussion about,
  -and anything else that might be useful to help the group track progress.
  -The active STATUS files are automatically posted to the mailing list
  -three times each week.
  -</P>
  -
  -<P>
  -Many issues will be encountered by the project, each resulting in zero
  -or more proposed action items.  Issues should be raised on the
  -mailing list as soon as they are identified.
  -Action items <STRONG>must</STRONG> be raised on the mailing list and
  -added to the relevant STATUS file.  All action items may be voted on,
  -but not all of them will require a formal vote.
  -</P>
  -
  -<H2><IMG SRC="images/apache_feather_bullet.gif" ALT="o ">
  -Voting</H2>
  -
  -<P>
  -Any of the Apache Developers may vote on any issue or action item.
  +      to ask the admin of <em>httpd.apache.org</em> for a user account.
  +  </dd>
  +</dl>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>STATUS</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<p>Each of the Apache Project's active source code repositories contain a 
  +file called "STATUS" which is used to keep track of the agenda and plans 
  +for work within that repository.  The STATUS file includes information 
  +about release plans, a summary of code changes committed since the last 
  +release, a list of proposed changes that are under discussion, brief 
  +notes about items that individual developers are working on or want 
  +discussion about, and anything else that might be useful to help the 
  +group track progress.  The active STATUS files are automatically posted 
  +to the mailing list each week.</p>
  +<p>Many issues will be encountered by the project, each resulting in 
  +zero or more proposed action items.  Issues should be raised on the
  +mailing list as soon as they are identified.  Action items 
  +<strong>must</strong> be raised on the mailing list and added to the 
  +relevant STATUS file.  All action items may be voted on, but not all 
  +of them will require a formal vote.</p>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>Voting</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<p>Any of the Apache Developers may vote on any issue or action item.
   However, the only binding votes are those cast by active members of the
  -Apache Group; if the vote is about a change to source code or documentation,
  -the primary author of what is being changed may also cast a binding vote
  -on that issue.  All other votes are non-binding.
  -All developers are encouraged to participate in decisions, but the decision
  -itself is made by those who have been long-time contributors to the project.
  -In other words, the Apache Project is a minimum-threshold meritocracy.
  -</P>
  -
  -<P>
  -The act of voting carries certain obligations -- voting members are not only
  -stating their opinion, they are agreeing to help do the work of the
  -Apache Project.  Since we are all volunteers, members often become inactive
  -for periods of time in order to take care of their "real jobs" or devote
  -more time to other projects. It is therefore unlikely that the entire group
  -membership will vote on every issue.  To account for this, all voting
  -decisions are based on a minimum quorum.
  -</P>
  -
  -<P>
  -Each vote can be made in one of three flavors:
  -
  -<DL COMPACT>
  -  <DT><STRONG>+1</STRONG></DT>
  -  <DD>Yes, agree, or the action should be performed.  On some issues, this
  +Apache Group; if the vote is about a change to source code or 
  +documentation, the primary author of what is being changed may also 
  +cast a binding vote on that issue.  All other votes are non-binding.
  +All developers are encouraged to participate in decisions, but the 
  +decision itself is made by those who have been long-time contributors 
  +to the project.  In other words, the Apache Project is a 
  +minimum-threshold meritocracy.</p>
  +<p>The act of voting carries certain obligations -- voting members are 
  +not only stating their opinion, they are agreeing to help do the work of 
  +the Apache Project.  Since we are all volunteers, members often become 
  +inactive for periods of time in order to take care of their "real jobs" 
  +or devote more time to other projects. It is therefore unlikely that the 
  +entire group membership will vote on every issue.  To account for this, 
  +all voting decisions are based on a minimum quorum.</p>
  +<p>Each vote can be made in one of three flavors:</p>
  +<dl compact="compact">
  +  <dt><strong>+1</strong></dt>
  +  <dd>Yes, agree, or the action should be performed.  On some issues, this
         vote is only binding if the voter has tested the action on
         their own system(s).
  -  </DD><P>
  -  <DT><STRONG>&#177;0</STRONG></DT>
  -  <DD>Abstain, no opinion, or I am happy to let the other group members
  +  </dd>
  +  <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 effects if
         too many people abstain.
  -  </DD><P>
  -  <DT><STRONG>-1</STRONG></DT>
  -  <DD>No. On issues where consensus is required, this vote counts as a
  -      <STRONG>veto</STRONG>.  All vetos must include an explanation of
  +  </dd>
  +  <dt><strong>-1</strong></dt>
  +  <dd>No. On issues where consensus is required, this vote counts as a
  +      <strong>veto</strong>.  All vetos must include an explanation of
         why the veto is appropriate.  A veto with no explanation is void.
         No veto can be overruled. If you disagree with the veto, you
         should lobby the person who cast the veto. Voters intending to veto
         an action item should make their opinions known to the group immediately,
         so that the problem can be remedied as early as possible.
  -  </DD>
  -</DL>
  -
  -<P>
  -An action item requiring <EM>consensus approval</EM> must receive
  -at least <STRONG>3 binding +1</STRONG> votes and <STRONG>no vetos</STRONG>.
  -An action item requiring <EM>majority approval</EM> must receive
  -at least <STRONG>3 binding +1</STRONG> votes and more <STRONG>+1</STRONG>
  -votes than <STRONG>-1</STRONG> votes (<EM>i.e.</EM>, a majority with a minimum
  +  </dd>
  +</dl>
  +<p>An action item requiring <em>consensus approval</em> must receive
  +at least <strong>3 binding +1</strong> votes and <strong>no vetos</strong>.
  +An action item requiring <em>majority approval</em> must receive
  +at least <strong>3 binding +1</strong> votes and more <strong>+1</strong>
  +votes than <strong>-1</strong> votes (<em>i.e.</em>, a majority with a minimum
   quorum of three positive votes).  All other action items are considered
  -to have <EM>lazy approval</EM> until someone votes <STRONG>-1</STRONG>,
  +to have <em>lazy approval</em> until someone votes <strong>-1</strong>,
   after which point they are decided by either consensus or a majority vote,
  -depending upon the type of action item.
  -</P>
  -
  -<P>
  -Votes are tallied within the STATUS file, adjacent to the action
  +depending upon the type of action item.</p>
  +<p>Votes are tallied within the STATUS file, adjacent to the action
   item under vote. All votes must be either sent to the mailing list
  -or added directly to the STATUS file entry for that action item.
  -</P>
  -
  -<H2><IMG SRC="images/apache_feather_bullet.gif" ALT="o ">
  -Types of Action Items</H2>
  -
  -<DL>
  -  <DT><STRONG>Long Term Plans</STRONG></DT>
  -  <DD>Long term plans are simply announcements that group members
  +or added directly to the STATUS file entry for that action item.</p>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>Types of Action Items</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<dl>
  +  <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,
         but group members who do not agree with a particular plan,
         or think an alternate plan would be better, are obligated to
         inform the group of their feelings.  In general, it is always
  -      better to hear about alternate plans <STRONG>prior</STRONG> to
  +      better to hear about alternate plans <strong>prior</strong> to
         spending time on less adequate solutions.
  +  </dd>
   
  -  <DT><STRONG>Short Term Plans</STRONG></DT>
  -  <DD>Short term plans are announcements that a developer is working on
  +  <dt><strong>Short Term Plans</strong></dt>
  +  <dd>Short term plans are announcements that a developer is working on
         a particular set of documentation or code files, with the implication
         that other developers should avoid them or try to coordinate their
         changes.  This is a good way to proactively avoid conflict and 
         possible duplication of work.
  +  </dd>
   
  -  <DT><STRONG>Release Plan</STRONG></DT>
  -  <DD>A release plan is used to keep all the developers aware of when a
  +  <dt><strong>Release Plan</strong></dt>
  +  <dd>A release plan is used to keep all the developers aware of when a
         release is desired, who will be the release manager, when the
         repository will be frozen in order to create the release, and 
         assorted other trivia to keep us from tripping over ourselves
         during the final moments.  Lazy majority decides each issue in
         the release plan.
  +  </dd>
   
  -  <DT><STRONG>Release Testing</STRONG></DT>
  -  <DD>After a new release is built, colloquially termed a tarball, it
  +  <dt><strong>Release Testing</strong></dt>
  +  <dd>After a new release is built, colloquially termed a tarball, it
         must be tested before being released to the public.  Majority
         approval is required before the tarball can be publically released.
  +  </dd>
   
  -  <DT><STRONG>Showstoppers</STRONG></DT>
  -  <DD>Showstoppers are issues that require a fix be in place
  +  <dt><strong>Showstoppers</strong></dt>
  +  <dd>Showstoppers are issues that require a fix be in place
         before the next public release.  They are listed in the STATUS file
         in order to focus special attention on the problem.  An issue becomes
         a showstopper when it is listed as such in STATUS and remains
         so by lazy consensus.
  +  </dd>
   
  -  <DT><STRONG>Product Changes</STRONG></DT>
  -  <DD>Changes to the Apache products, including code and documentation,
  +  <dt><strong>Product Changes</strong></dt>
  +  <dd>Changes to the Apache products, including code and documentation,
         will appear as action items under several categories corresponding
         to the change status:
  -      <DL>
  -      <DT><STRONG>concept/plan</STRONG>
  -      <DD>An idea or plan for a change.  These are usually only listed in
  +      <dl>
  +      <dt><strong>concept/plan</strong></dt>
  +      <dd>An idea or plan for a change.  These are usually only listed in
             STATUS when the change is substantial, significantly impacts the
             API, or is likely to be controversial.  Votes are being requested
             early so as to uncover conflicts before too much work is done.
  -      <DT><STRONG>proposed patch</STRONG>
  -      <DD>A specific set of changes to the current product in the form
  -          of <A HREF="#patch">input to the patch command</A> (a diff output).
  -      <DT><STRONG>committed change</STRONG>
  -      <DD>A one-line summary of a change that has been committed to the
  +      </dd>
  +      <dt><strong>proposed patch</strong></dt>
  +      <dd>A specific set of changes to the current product in the form
  +          of <a href="#patch">input to the patch command</a> (a diff output).
  +      </dd>
  +      <dt><strong>committed change</strong></dt>
  +      <dd>A one-line summary of a change that has been committed to the
             repository since the last public release.
  -      </DL>
  -      All product changes to the currently active repository are subject
  +      </dd>
  +      </dl>
  +      <p>All product changes to the currently active repository are subject
         to lazy consensus.  All product changes to a prior-branch (old version)
  -      repository require consensus before the change is committed.
  -</DL>
  -
  -<H2><IMG SRC="images/apache_feather_bullet.gif" ALT="o ">
  -When to Commit a Change</H2>
  -
  -<P>
  -Ideas must be review-then-commit; patches can be commit-then-review.
  +      repository require consensus before the change is committed.</p>
  +  </dd>
  +</dl>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>When to Commit a Change</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<p>Ideas must be review-then-commit; patches can be commit-then-review.
   With a commit-then-review process, we trust that the developer doing the
   commit has a high degree of confidence in the change.  Doubtful changes,
   new features, and large-scale overhauls need to be discussed before
  @@ -251,93 +316,102 @@
   of arguments to configurable directives, significantly adds to the runtime
   size of the program, or changes the semantics of an existing API function
   must receive consensus approval on the mailing list before being committed.
  -</P>
  -
  -<P>
  -Each developer is responsible for notifying the mailing list and adding
  -an action item to STATUS when they have an idea for a new feature or
  -major change to propose for the product.  The distributed nature of the
  +</p>
  +<p>Each developer is responsible for notifying the mailing list and 
  +adding an action item to STATUS when they have an idea for a new feature 
  +or major change to propose for the product.  The distributed nature of the
   Apache project requires an advance notice of 48 hours in order to properly
   review a major change -- consensus approval of either the concept or a
   specific patch is required before the change can be committed.  Note that
   a member might veto the concept (with an adequate explanation), but later
   rescind that veto if a specific patch satisfies their objections.
  -No advance notice is required to commit singular bug fixes.
  -</P>
  -
  -<P>
  -Related changes should be committed as a group, or very closely together.
  -Half-completed projects should not be committed unless doing so is
  -necessary to pass the baton to another developer who has agreed to
  -complete the project in short order.  All code changes must be successfully
  -compiled on the developer's platform before being committed.
  -</P>
  -
  -<P>
  -The current source code tree should be capable of complete compilation
  +No advance notice is required to commit singular bug fixes.</p>
  +<p>Related changes should be committed as a group, or very closely 
  +together.  Half-completed projects should not be committed unless 
  +doing so is necessary to pass the baton to another developer who has 
  +agreed to complete the project in short order.  All code changes must 
  +be successfully compiled on the developer's platform before being 
  +committed.</p>
  +<p>The current source code tree should be capable of complete compilation
   at all times.  However, it is sometimes impossible for a developer on
   one platform to avoid breaking some other platform when a change is
   committed, particularly when completing the change requires access to
   a special development tool on that other platform.  If it is anticipated
   that a given change will break some other platform, the committer must
  -indicate that in the commit log.
  -</P>
  -
  -<P>
  -The committer is responsible for the quality of any third-party code
  +indicate that in the commit log.</p>
  +<p>The committer is responsible for the quality of any third-party code
   or documentation they commit to the repository.  All software committed
   to the repository must be covered by the Apache LICENSE or contain a
   copyright and license that allows redistribution under the same conditions
  -as the Apache LICENSE.
  -</P>
  -
  -<P>
  -A committed change must be reversed if it is vetoed by one of the voting
  -members and the veto conditions cannot be immediately satisfied by the
  -equivalent of a "bug fix" commit.  The veto must be rescinded before the
  -change can be included in any public release.
  -</P>
  -
  -<H2><IMG SRC="images/apache_feather_bullet.gif" ALT="o ">
  -<A NAME="patch">Patch Format</A></H2>
  -
  -<P>
  -When a specific change to the software is proposed for discussion or
  -voting on the mailing list, it should be presented in
  -the form of input to the patch command.  When sent to the mailing list,
  -the message should contain a Subject beginning with
  -<CODE>[PATCH]</CODE> and a distinctive one-line summary
  -corresponding to the action item for that patch.  Afterwords, the patch
  -summary in the STATUS file should be updated to point to the Message-ID
  -of that message.
  -
  -<P>
  -The patch should be created by using the <CODE>diff -u</CODE> command
  -from the original software file(s) to the modified software file(s).
  -E.g.,</P>
  -
  -<PRE>    diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt</PRE>
  -or
  -<PRE>    cvs diff -u http_main.c &gt;&gt; patchfile.txt</PRE>
  -
  -<P>
  -All patches necessary to address an action item should be concatenated
  +as the Apache LICENSE.</p>
  +<p>A committed change must be reversed if it is vetoed by one of the 
  +voting members and the veto conditions cannot be immediately satisfied by 
  +the equivalent of a "bug fix" commit.  The veto must be rescinded before 
  +the change can be included in any public release.</p>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <a name="patch"><strong>Patch Format</strong></a>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<p>When a specific change to the software is proposed for discussion or
  +voting on the mailing list, it should be presented in the form of input 
  +to the patch command.  When sent to the mailing list, the message 
  +should contain a Subject beginning with <code>[PATCH]</code> and a 
  +distinctive one-line summary corresponding to the action item for that 
  +patch.  Afterwords, the patch summary in the STATUS file should be 
  +updated to point to the Message-ID of that message.</p>
  +<p>The patch should be created by using the <CODE>diff -u</CODE> 
  +command from the original software file(s) to the modified software 
  +file(s).  E.g.,</p>
  +<pre>    diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt</pre>
  +<p>or</p>
  +<pre>    cvs diff -u http_main.c &gt;&gt; patchfile.txt</pre>
  +<p>All patches necessary to address an action item should be concatenated
   within a single patch message.  If later modification of the patch
   proves necessary, the entire new patch should be posted and not just
   the difference between two patches.  The STATUS file entry should then
  -be updated to point to the new patch message.
  -
  -<P>The completed patchfile should produce no errors or prompts when the
  -command,</P>
  -<PRE>    patch -s &lt; patchfile</PRE>
  -is issued in the target repository.
  -
  -<H2>Addendum: Outstanding issues with this document</H2>
  -<UL>
  -<LI>We may need a better definition for "lazy consensus".
  -<LI>We should clarify under what conditions a veto can be rescinded or overridden.
  -<LI>Should we set a time limit on vetos of patches?  Two weeks?
  -</UL>
  -
  -</BODY> 
  -</HTML>     
  +be updated to point to the new patch message.</p>
  +<p>The completed patchfile should produce no errors or prompts when the
  +command,</p>
  +<pre>    patch -s &lt; patchfile</pre>
  +<p>is issued in the target repository.</p>
  +  </blockquote>
  + </td></tr>
  +</table>
  +           <table border="0" cellspacing="0" cellpadding="2" width="100%">
  + <tr><td bgcolor="#525D76">
  +  <font color="#ffffff" face="arial,helvetica,sanserif">
  +   <strong>Addendum</strong>
  +  </font>
  + </td></tr>
  + <tr><td>
  +  <blockquote>
  +<p>Outstanding issues with this document</p>
  +<ul>
  +    <li>We may need a better definition for "lazy consensus".</li>
  +    <li>We should clarify under what conditions a veto can be rescinded 
  +        or overridden.</li>
  +    <li>Should we set a time limit on vetos of patches?  Two weeks?</li>
  +</ul>
  +  </blockquote>
  + </td></tr>
  +</table>
  +         </td>
  +   </tr>
  +   <!-- FOOTER -->
  +   <tr><td colspan="2"><hr noshade="noshade" size="1"/></td></tr>
  +   <tr><td colspan="2" align="center">
  +        <font size="-1">
  +         <em>Copyright &#169; 1999-2001, The Apache Software Foundation</em>
  +        </font>
  +       </td>
  +   </tr>
  +  </table>
  + </body>
  +</html>
  
  
  
  1.1                  httpd-site/xdocs/dev/guidelines.xml
  
  Index: guidelines.xml
  ===================================================================
  <?xml version="1.0"?>
  <document>
    <properties>
      <author email="docs@httpd.apache.org">Documentation Group</author>
      <title>Apache HTTPD Project Guidelines and Voting Rules</title>
    </properties>
  <body>
  
  <section><title>Apache Project Guidelines</title>
  
  <p>This document defines the guidelines for the
  <a href="http://httpd.apache.org/">Apache HTTPD Project</a>.
  It includes definitions of how conflict is resolved by voting,
  who is able to vote, and the procedures to follow for proposing and 
  making changes to the Apache products.</p>
  
  <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>
  </section>
  
  <section><title>People, Places, and Things</title>
  
  <dl>
    <dt><strong>Apache Group</strong></dt>
    <dd>The group of volunteers who are responsible for managing the
        Apache Project.  This includes deciding what is distributed as
        products of the Apache Project, maintaining the Project's shared
        resources, speaking on behalf of the Apache Project, resolving
        license disputes regarding Apache products, and establishing
        these guidelines.
  
        <p>Membership in the Apache Group is by invitation only and must
        be approved by consensus of the active Apache Group members.
        A member is considered inactive by their own declaration or by not
        contributing in any form to the project for over six months.  An
        inactive member can become active again by reversing whichever condition
        made them inactive (<em>i.e.</em>, by reversing their earlier
        declaration or by once again contributing toward the project's work).
        Membership can be revoked by a unanimous vote of all the active 
        members other than the member in question.</p>
    </dd>
  
    <dt><strong>Apache Developers</strong></dt>
    <dd>All of the volunteers who are contributing time, code, documentation,
        or resources to the Apache Project.  A developer that makes sustained,
        welcome contributions to the project for over six months is usually
        invited to join the Apache Group, though the exact timing of such
        invitations depends on many factors.</dd>
  
    <dt><strong>mailing list</strong></dt>
    <dd>The Apache developers' primary mailing list for discussion of issues
        and changes related to the project (<em>dev@httpd.apache.org</em>).
        Subscription to the list is open, but only subscribers
        can post directly to the list.
    </dd>
  
    <dt><strong>private list</strong></dt>
    <dd>The Apache Group's private mailing list for discussion of issues
        that are inappropriate for public discussion, such as legal, personal,
        or security issues prior to a published fix.  Subscription to the list
        is only open to Apache Group members.
    </dd>
  
    <dt><strong>CVS</strong></dt>
    <dd>All of the Apache products are maintained in shared information
        repositories using <a href="devnotes.html">CVS on
        <em>httpd.apache.org</em></a>.  Only some of the Apache developers have
        write access to these repositories; everyone has read access via
        <a href="anoncvs">anonymous CVS</a>.  Developers who want write
        access need to ask for it on the mailing list and, if approved, need
        to ask the admin of <em>httpd.apache.org</em> for a user account.
    </dd>
  </dl>
  </section>
  
  <section><title>STATUS</title>
  
  <p>Each of the Apache Project's active source code repositories contain a 
  file called "STATUS" which is used to keep track of the agenda and plans 
  for work within that repository.  The STATUS file includes information 
  about release plans, a summary of code changes committed since the last 
  release, a list of proposed changes that are under discussion, brief 
  notes about items that individual developers are working on or want 
  discussion about, and anything else that might be useful to help the 
  group track progress.  The active STATUS files are automatically posted 
  to the mailing list each week.</p>
  
  <p>Many issues will be encountered by the project, each resulting in 
  zero or more proposed action items.  Issues should be raised on the
  mailing list as soon as they are identified.  Action items 
  <strong>must</strong> be raised on the mailing list and added to the 
  relevant STATUS file.  All action items may be voted on, but not all 
  of them will require a formal vote.</p>
  </section>
  
  <section><title>Voting</title>
  
  <p>Any of the Apache Developers may vote on any issue or action item.
  However, the only binding votes are those cast by active members of the
  Apache Group; if the vote is about a change to source code or 
  documentation, the primary author of what is being changed may also 
  cast a binding vote on that issue.  All other votes are non-binding.
  All developers are encouraged to participate in decisions, but the 
  decision itself is made by those who have been long-time contributors 
  to the project.  In other words, the Apache Project is a 
  minimum-threshold meritocracy.</p>
  
  <p>The act of voting carries certain obligations -- voting members are 
  not only stating their opinion, they are agreeing to help do the work of 
  the Apache Project.  Since we are all volunteers, members often become 
  inactive for periods of time in order to take care of their "real jobs" 
  or devote more time to other projects. It is therefore unlikely that the 
  entire group membership will vote on every issue.  To account for this, 
  all voting decisions are based on a minimum quorum.</p>
  
  <p>Each vote can be made in one of three flavors:</p>
  
  <dl compact="compact">
    <dt><strong>+1</strong></dt>
    <dd>Yes, agree, or the action should be performed.  On some issues, this
        vote is only binding if the voter has tested the action on
        their own system(s).
    </dd>
    <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 effects if
        too many people abstain.
    </dd>
    <dt><strong>-1</strong></dt>
    <dd>No. On issues where consensus is required, this vote counts as a
        <strong>veto</strong>.  All vetos must include an explanation of
        why the veto is appropriate.  A veto with no explanation is void.
        No veto can be overruled. If you disagree with the veto, you
        should lobby the person who cast the veto. Voters intending to veto
        an action item should make their opinions known to the group immediately,
        so that the problem can be remedied as early as possible.
    </dd>
  </dl>
  
  <p>An action item requiring <em>consensus approval</em> must receive
  at least <strong>3 binding +1</strong> votes and <strong>no vetos</strong>.
  An action item requiring <em>majority approval</em> must receive
  at least <strong>3 binding +1</strong> votes and more <strong>+1</strong>
  votes than <strong>-1</strong> votes (<em>i.e.</em>, a majority with a minimum
  quorum of three positive votes).  All other action items are considered
  to have <em>lazy approval</em> until someone votes <strong>-1</strong>,
  after which point they are decided by either consensus or a majority vote,
  depending upon the type of action item.</p>
  
  <p>Votes are tallied within the STATUS file, adjacent to the action
  item under vote. All votes must be either sent to the mailing list
  or added directly to the STATUS file entry for that action item.</p>
  
  </section>
  
  <section><title>Types of Action Items</title>
  <dl>
    <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,
        but group members who do not agree with a particular plan,
        or think an alternate plan would be better, are obligated to
        inform the group of their feelings.  In general, it is always
        better to hear about alternate plans <strong>prior</strong> to
        spending time on less adequate solutions.
    </dd>
  
    <dt><strong>Short Term Plans</strong></dt>
    <dd>Short term plans are announcements that a developer is working on
        a particular set of documentation or code files, with the implication
        that other developers should avoid them or try to coordinate their
        changes.  This is a good way to proactively avoid conflict and 
        possible duplication of work.
    </dd>
  
    <dt><strong>Release Plan</strong></dt>
    <dd>A release plan is used to keep all the developers aware of when a
        release is desired, who will be the release manager, when the
        repository will be frozen in order to create the release, and 
        assorted other trivia to keep us from tripping over ourselves
        during the final moments.  Lazy majority decides each issue in
        the release plan.
    </dd>
  
    <dt><strong>Release Testing</strong></dt>
    <dd>After a new release is built, colloquially termed a tarball, it
        must be tested before being released to the public.  Majority
        approval is required before the tarball can be publically released.
    </dd>
  
    <dt><strong>Showstoppers</strong></dt>
    <dd>Showstoppers are issues that require a fix be in place
        before the next public release.  They are listed in the STATUS file
        in order to focus special attention on the problem.  An issue becomes
        a showstopper when it is listed as such in STATUS and remains
        so by lazy consensus.
    </dd>
  
    <dt><strong>Product Changes</strong></dt>
    <dd>Changes to the Apache products, including code and documentation,
        will appear as action items under several categories corresponding
        to the change status:
        <dl>
        <dt><strong>concept/plan</strong></dt>
        <dd>An idea or plan for a change.  These are usually only listed in
            STATUS when the change is substantial, significantly impacts the
            API, or is likely to be controversial.  Votes are being requested
            early so as to uncover conflicts before too much work is done.
        </dd>
        <dt><strong>proposed patch</strong></dt>
        <dd>A specific set of changes to the current product in the form
            of <a href="#patch">input to the patch command</a> (a diff output).
        </dd>
        <dt><strong>committed change</strong></dt>
        <dd>A one-line summary of a change that has been committed to the
            repository since the last public release.
        </dd>
        </dl>
        <p>All product changes to the currently active repository are subject
        to lazy consensus.  All product changes to a prior-branch (old version)
        repository require consensus before the change is committed.</p>
    </dd>
  </dl>
  </section>
  
  <section><title>When to Commit a Change</title>
  
  <p>Ideas must be review-then-commit; patches can be commit-then-review.
  With a commit-then-review process, we trust that the developer doing the
  commit has a high degree of confidence in the change.  Doubtful changes,
  new features, and large-scale overhauls need to be discussed before
  being committed to a repository. Any change that affects the semantics
  of arguments to configurable directives, significantly adds to the runtime
  size of the program, or changes the semantics of an existing API function
  must receive consensus approval on the mailing list before being committed.
  </p>
  
  <p>Each developer is responsible for notifying the mailing list and 
  adding an action item to STATUS when they have an idea for a new feature 
  or major change to propose for the product.  The distributed nature of the
  Apache project requires an advance notice of 48 hours in order to properly
  review a major change -- consensus approval of either the concept or a
  specific patch is required before the change can be committed.  Note that
  a member might veto the concept (with an adequate explanation), but later
  rescind that veto if a specific patch satisfies their objections.
  No advance notice is required to commit singular bug fixes.</p>
  
  <p>Related changes should be committed as a group, or very closely 
  together.  Half-completed projects should not be committed unless 
  doing so is necessary to pass the baton to another developer who has 
  agreed to complete the project in short order.  All code changes must 
  be successfully compiled on the developer's platform before being 
  committed.</p>
  
  <p>The current source code tree should be capable of complete compilation
  at all times.  However, it is sometimes impossible for a developer on
  one platform to avoid breaking some other platform when a change is
  committed, particularly when completing the change requires access to
  a special development tool on that other platform.  If it is anticipated
  that a given change will break some other platform, the committer must
  indicate that in the commit log.</p>
  
  <p>The committer is responsible for the quality of any third-party code
  or documentation they commit to the repository.  All software committed
  to the repository must be covered by the Apache LICENSE or contain a
  copyright and license that allows redistribution under the same conditions
  as the Apache LICENSE.</p>
  
  <p>A committed change must be reversed if it is vetoed by one of the 
  voting members and the veto conditions cannot be immediately satisfied by 
  the equivalent of a "bug fix" commit.  The veto must be rescinded before 
  the change can be included in any public release.</p>
  
  </section>
  
  <section id="patch"><title>Patch Format</title>
  <p>When a specific change to the software is proposed for discussion or
  voting on the mailing list, it should be presented in the form of input 
  to the patch command.  When sent to the mailing list, the message 
  should contain a Subject beginning with <code>[PATCH]</code> and a 
  distinctive one-line summary corresponding to the action item for that 
  patch.  Afterwords, the patch summary in the STATUS file should be 
  updated to point to the Message-ID of that message.</p>
  
  <p>The patch should be created by using the <CODE>diff -u</CODE> 
  command from the original software file(s) to the modified software 
  file(s).  E.g.,</p>
  
  <pre>    diff -u http_main.c.orig http_main.c &gt;&gt; patchfile.txt</pre>
  <p>or</p>
  <pre>    cvs diff -u http_main.c &gt;&gt; patchfile.txt</pre>
  
  <p>All patches necessary to address an action item should be concatenated
  within a single patch message.  If later modification of the patch
  proves necessary, the entire new patch should be posted and not just
  the difference between two patches.  The STATUS file entry should then
  be updated to point to the new patch message.</p>
  
  <p>The completed patchfile should produce no errors or prompts when the
  command,</p>
  <pre>    patch -s &lt; patchfile</pre>
  <p>is issued in the target repository.</p>
  </section>
  
  <section><title>Addendum</title>
  
  <p>Outstanding issues with this document</p>
  
  <ul>
      <li>We may need a better definition for "lazy consensus".</li>
      <li>We should clarify under what conditions a veto can be rescinded 
          or overridden.</li>
      <li>Should we set a time limit on vetos of patches?  Two weeks?</li>
  </ul>
  </section>
  
  </body>
  </document>
  
  
  

Mime
View raw message