APR Project Guidelines
This page describes the procedures and guidelines used by the APR
Commit access will be somewhere between the "lengthy" process of httpd,
and the more "open" process in Subversion.
Specifically, if a person submits several reasonable patches that apply
well and follow the general guidelines, and that person appears to "get the
process", then they will be provided commit access.
This policy generally depends upon the fact that we can always recover
from problematic committers (since we use source control). The PMC also
reserves the right to suspend commit privileges, if other APR members end up
spending too much time dealing with problematic commits.
Most changes (bug fixes and minor, commonsense feature adds) do not
require review. Developers are encouraged to request review for:
- Large changes affecting many files
- Changes to interfaces
- Changes that commit APR to one option out of an exclusive set
- Any change the developer wants a second (or Nth) opinion on
Anyone may retroactively cause someone's change to be reviewed by
requesting review after it was committed, and at their discretion may
revert the change until it is approved.
The above process is called "Commit Then Review" (or CTR). As of
this time, the group does not see a need to ever use a "Review
Then Commit" (RTC) process.
The goals for CHANGES entries are to provide this documentation
for user-visible changes and to limit this documentation to releases
which introduced the change. Fixes to features which have not yet been
released don't warrant an entry as they are part of the initial release
of the feature. CHANGES for one branch shouldn't duplicate entries for
earlier branches except when releases introducing the fix are created
from both branches.
Modifications expected to remain only in trunk, at least for some
time, should be accompanied by a CHANGES entry in trunk (if a CHANGES
entry is appropriate at all).
Many changes which are committed to trunk are also delivered to other
branches. The procedure used is outlined below.
Commit to trunk, 1.9.x, 1.8.x, etc. down to the actively maintained
stable branch. In cases where the actively maintained stable branch
has recently changed, such as when moving from 1.3.x to 1.4.x in order
to release new features, it is up to the committer to decide whether to
commit to the previous actively maintained stable branch. (There is
at least limited value in having the project decide what the patch for
some branch is even if there are no clear plans to release it, as some
users may need to continue using the previous branch for some time
until they can vet the changes in the current branch.)
Commit messages for the branches always explicitly reference the trunk
revision. In particular, note that Subversion mergeinfo is not a
sufficient record because it does not show up in commonly-used views of
When a CHANGES entry is needed for the modifications committed to a
branch, the CHANGES entry should be part of the commit, whether or not
it was part of the trunk revision being backported. (A CHANGES entry is
commonly omitted from the trunk commit if a backport will be performed
PMC membership is attained through a "consensus approval" process
according to the standard ASF guidelines (as set out by HTTP Server). The voters are the
existing PMC members.
The general policy is to accept committers who have demonstrated
longevity in dev/doc/admin ability and interest in the APR project.
Decision Making: Consensus and Voting
The following text describes the precise rules and procedure
for voting and decision making. In general, the behavior
embodied in these rules is part of the "gestalt" of the group,
and the formal use of these processes is not required.
Whenever possible, decisions are made by consensus. Consensus is reached
when both the following conditions are met: a committer indicates that
consensus has been reached, and no committer claims that consensus has not yet
been reached. On any given issue, there is a 72-hour window after a claim of
consensus before the consensus is considered binding, to give people time to
[ gjs: changes can always be reverted, so why a window?
and why is a decision ever "binding"? ]
[ gjs: need some text that describes the use of +/- 0/1 for
talking about changes and their use in deciding whether
consensus has been reached ]
For decisions on which consensus is not reachable or is not attempted,
the group votes, using approval voting:
Each voter is allowed to cast a single vote for each of as many of the
ballot choices as desired -- that is, the voter votes for all choices of which
the voter "approves." Each vote is one of:
- +1 : Yes, agree that the choice should be performed.
- +0 : Seems fine, but I can live without it
- -0 : Doesn't seem right, but I won't argue against it
- -1 : No, I am against this choice being performed.
Choices receiving positive totals may be performed.
When the set of ballot choices cannot be agreed on, the PMC chair decides
the set. If the question of whether consensus has been reached or not is
undecidable (this "can't happen", but who knows), the chair decides whether or
not it has been reached.
Changes to these decision-making procedures may be made by consensus. But,
if such a change does reach the voting stage, then positive votes must
outnumber negative votes by a two-to-one ratio, or greater, for the change to
Veto as a vote
A voter explicitly stating that they veto the decision, providing a
justification of their veto is sufficient to table a vote until the issue is
addressed and the vetoer or those who agreed concur that the the issue is
Voting Procedure Technicalities
Votes are tallied in 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.