You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by fi...@hyperreal.org on 1998/01/12 02:53:37 UTC
cvs commit: apache-devsite guidelines.html
fielding 98/01/11 17:53:37
Added: . guidelines.html
Log:
A start on a complete update of the Apache Project voting rules
and guidelines.
Revision Changes Path
1.1 apache-devsite/guidelines.html
Index: guidelines.html
===================================================================
<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 and Voting Rules</H1>
<P><B>DRAFT</B>: These guidelines are not yet approved.</P>
</CENTER>
<P>
This document defines the rules and guidelines for the Apache Project.
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>
<P>
The following define some common terms:
</P>
<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 rules and 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 (i.e., 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>
<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>
<DT><STRONG>mailing list</STRONG></DT>
<DD>The Apache developers' primary mailing list for discussion of issues
and changes related to the project (<i>new-httpd@apache.org</i>).
Subscription to the list is open, but only subscribers
can post directly to the list.</DD><P>
<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>
<DT><STRONG>CVS</STRONG></DT>
<DD>All of the Apache products are maintained in shared information
repositories using <a href="devnotes.html">CVS on
<i>dev.apache.org</i>.</a> Only some of the Apache developers have
write access to these repositories; everyone has read access via
<a href="anoncvs.txt">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 <i>dev.apache.org</i> for a user account.</DD>
</DL>
<HR SIZE=6>
<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.
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 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
vote is only binding if the voter has tested the action on
their own system(s).
</DD><P>
<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
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</em> must receive
at least <STRONG>3 binding +1</STRONG> votes and <STRONG>no vetos</STRONG>.
An action item requiring <em>simple approval</em> must receive
at least <STRONG>3 binding +1</STRONG> votes and more <STRONG>+1</STRONG>
votes than <STRONG>-1</STRONG> votes (i.e., a majority with a minimum
quorum of three positive votes).
</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>Release Testing</STRONG></DT>
<DT><STRONG>Release Plan</STRONG></DT>
<DT><STRONG>Showstoppers</STRONG></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><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
changes are being made. If the changes are to existing documents,
the existing documents should not be replaced until at least
24 hours after notifying the list. Any group member may veto a
change, but must then provide real assistance to the author
in correcting the problem if it can be corrected, and must rescind
the veto once the problem has been corrected (this may be assumed
in good faith).</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.
<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.
</DL>
<H2><IMG SRC="images/apache_feather_bullet.gif" alt="o ">
To Commit, or Not to Commit?</H2>
<P>
We are exploring a new system to help speed development,
"commit-then-review". With a commit-then-review, we trust that
committers have a high degree of confidence in their committed patches
--- higher than the typical [PATCH] post to new-httpd.
<UL>
<LI>Advance notice (eg: "I'll be working on flurgl.c") will be given;
this will help in cause others wish to help and to avoid
stepping on people's toes/concurrent patches on the same code.
<LI>The CVS tree should be expected to compile at all times
<LI>Experimental new features must be discussed before implemented
<LI>The committer is responsible for the quality of the third-party code
they bring into the code.
<LI>Related changes should be posted at once, or very closely together;
no half-baked projects in the code.
<LI>Any changes:</BR>
<UL>
<LI>which affect semantics of arguments to directives
<LI>which would have to be implemented differently on other architectures
<LI>which significantly add to the runtime size of the program
</UL>
need to be discussed on new-httpd before it gets committed.
<LI>A patch must be reversed if the equivalent of a "veto" comes from
another developer with commit access.
</UL>
<HR size="6">Remainder has not been re-edited yet. ...Roy
<H3>Patch Format</H3>
<P>
Unless it is infeasible to do so, source code changes must be proposed in
the form of input to the patch command. Feasibility is defined by each
voter and the version builder(s), who may veto an action item if the
action requires effort beyond what they are expected to perform.
<P>The patch should be created by using <CODE>diff -u</CODE> on the
<STRONG>CURRENT</STRONG> source and the modified source. E.g.,</P>
<PRE> diff -u http_main.c.orig http_main.c</PRE>
<P>All patches necessary to address an action item must be concatenated
within a single patchfile. The source files affected by the patchfile
should be listed in an Affects header.</P>
<P>The completed patchfile should produce no errors or prompts when the
command,</P>
<PRE> patch -s < patchfile</PRE>
is issued.
<P>If the patch produces errors or prompts, then it may be rejected by
others. Problems with patches should be reported to the mailing list
as soon as they are noticed. Dependencies between patches must be
noted with a Requires line in the patchfile headers.</P>
<H3>Alternate Patches</H3>
<P>Once uploaded, changes to the contents of a patchfile are limited
to the header information (i.e., everything other than the patch itself).
For example, the Changelog entry can be changed, but not the output
of the <CODE>diff</CODE> command(s).
<P>Should the patch itself need changing, a new patchfile should be created
with a new patchletter after the ID. Anyone can upload a patch to address
a single problem, so alternative patches can be offered for the same problem.
The author of the patch is the only person allowed to (or give permission to)
have an existing patch removed. Removal of a patch means removal of the
patchfile.</P>
<P>Each patchfile is voted on independently. New alternate patches must
garner their own votes -- they do not automatically inherit the votes
for patches they replace.</P>
<P>Patches for <STRONG>CURRENT</STRONG> can be uploaded at any time before or
during a voting session.</P>
<H3>Release Build and Announcement</H3>
<P>Unless stated otherwise at the start of the vote session, all releases
are 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 it is to be released publically, everyone on the mailing
list should make the effort to download it and try it out.
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 <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>
<H3><A name="emergency">Emergency Patch Votes</A></H3>
<P>In the event of an emergency patch/vote session to fix a security
problem, the group may need to bypass the normal operating procedures
described above in order to get a fix in place prior to any public
announcement of the problem. Any group member may announce an emergency
on the mailing list and is encouraged to do so immediately if notified
about a severe problem. Any group member may veto an emergency in order
to force it through the normal procedures.</P>
<P>Patches created to solve an emergency problem may be linked directly
from the Apache home page as soon as the patch has been created and
tested by its author. However, this link must be removed or changed
if the original patch is vetoed.</P>
<P>The availability of an emergency patch may be announced to the public
after 24hours or three +1 votes are given for the patch, whichever comes
first.</P>
</BODY>
</HTML>