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.
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.
Some abbreviations used below...
Anyone on the mailing list may vote on any issue. However, 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.
Each vote can be made in one of three flavors:
All votes must be sent to the mailing list.
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. However, also see the section on lazy voting mode.
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.
Patch providers include anyone that has an action item to propose. 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.
Action items (usually patches) are uploaded to hyperreal (apache.org) via FTP, either directly into the directory for patches to CURRENT (/httpd/patches/for_Apache_C_VERSION/), or into an incoming FTP directory for later transfer into the patch directory.
Each filename should at least hint at the action objective and include reference to:
The syntax for filenames not containing patches is:
01.Modula3_rewriteif the action item is not (yet) in the form of a patch.
The syntax for filenames containing patches is:
01.ScriptAliasKaboom.0.8.11.patch 01a.ScriptAliasKaboom.0.8.11.patch 01b.ScriptAliasKaboom.0.8.11.patch
The ID number should start at 01, and be incremented for each new action item uploaded.
An action item should contain a list of header information (formatted like e-mail or HTTP headers):
The patch should be created by using
diff -u on the
CURRENT source and the modified source. E.g.,
diff -u http_main.c.orig http_main.c
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.
The completed patchfile should produce no errors or prompts when the command,
patch -s < patchfileis issued.
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.
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
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.
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.
Patches for CURRENT can be uploaded at any time before or during a voting session.
A voting session can be initiated by anyone so long as a volunteer or volunteers can be found to:
The person or persons volunteering to perform these tasks agree on a timetable and announce it on the mailing list. The important part of the timetable is the vote deadline, which specifies when the votes will be tallied and the new version can be built. Unless it is an emergency, the initial deadline should be at least three days after the announcement.
The vote deadline can be moved if, using the same voting rules as for patches, there are enough votes and no vetos. The current deadline cannot be voted on.
Group members can vote and comment on the patches under consideration as often as they want. The final vote (if votes are changed) of a person is assumed to invalidate previous votes.
Votes are cast as follows;
No veto can be overruled. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto a patch should make their opinions known to the group immediately, so that the problem can be remedied prior to the vote deadline, if possible.
Votes are tallied by the vote coordinator as soon as the final vote deadline has passed. The results of the vote are then posted to the mailing list.
In order to be approved, an action item file must receive at least 3 positive votes and NO vetos.
Late +1 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.
After the vote coordinator gives the version builder the results, NEXT is created by applying the approved patches to CURRENT, 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.
NEXT 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.
After the version announcement, accidental mistakes made by the builder can be rectified without a vote, but must be announced to the group.
Unless stated otherwise at the start of the vote session, NEXT 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.
If NEXT is to be released publically, everyone on the mailing list should make the effort to download it and try it out. NEXT should not be publically released until 24 hours after it has been created and announced to the group.
If one of the patches used to create NEXT 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.
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.
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.
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.
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 formal voting process, except that "silence gives assent" -- if 48 hours pass without a veto, a quorum of "aye" votes is assumed even not officially collected.
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.
When a patch submitter expects to take advantage of lazy voting mode, it must be explicitly stated in the patch submission.