The Apache Portable Runtime Project

Get Involved

  • Subversion
  • Mailing Lists
  • Build on Win32
  • Build on Unix
  • Download!

  • from a mirror
  • APR Docs

  • Version 1.7
  • Trunk APR 2.0 (dev preview)
  • APR-util Docs

  • Version 1.6
  • Trunk APR 2.0 (dev preview)
  • APR-iconv Docs

  • Version 1.2
  • Trunk (dev preview)
  • Guidelines

  • Project Guidelines
  • Contributing
  • Version Numbers
  • Miscellaneous

  • License
  • Security Reports
  • Projects using APR
  • Thanks!
  • Sponsorship
  • Foundation
  • Events
  • Privacy Policy
  • APR Project Guidelines

    This page describes the procedures and guidelines used by the APR Project.

    Commit Access

    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.

    Change Process

    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.

    CHANGES entries

    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).

    Branch maintenance

    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 revision history.

    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 almost immediately.)

    PMC Membership

    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 react.

    [ 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 take effect.

    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 addressed.

    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.

    Copyright © 2008-2021, The Apache Software Foundation
    Apache Portable Runtime, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.