The Apache Portable Runtime Project

Get Involved

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

  • from a mirror
  • APR Docs

  • Version 1.2
  • Version 0.9
  • Trunk (dev)
  • APR-util Docs

  • Version 1.2
  • Version 0.9
  • Trunk (dev)
  • APR-iconv Docs

  • Version 1.1
  • Version 0.9
  • Trunk (dev)
  • Guidelines

  • Project Guidelines
  • Contributing
  • Version Numbers
  • Miscellaneous

  • License
  • Projects using APR
  • Security Reports
  • APR Project Guidelines

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

    this is an initial draft

    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.

    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
    NOTE:
    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 © 1999-2003, The Apache Software Foundation