gstein 00/11/24 16:54:51 Modified: . index.html Added: . guidelines.html Log: *) put the most-accepted mission statement on the home page *) you have "a runtime" or you do things "at run-time". APR is the former, so update the home page. *) add first-draft guidelines.html to accept/formalize the discussions from the PMC. Revision Changes Path 1.7 +25 -13 apr-site/index.html Index: index.html =================================================================== RCS file: /home/cvs/apr-site/index.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -u -r1.6 -r1.7 --- index.html 2000/11/20 22:44:15 1.6 +++ index.html 2000/11/25 00:54:51 1.7 @@ -2,33 +2,45 @@ "http://www.w3.org/TR/REC-html40/loose.dtd"> - The Apache Portable Run-Time + The Apache Portable Runtime + - +
The Apache Software Foundation

Portable Run-Time Project

Portable Runtime Project

- This is a new Apache Software Foundation project that hopes to create a - library of routines that can be used on any platform to create stable - programs. + The mission of the Apache Portable Runtime (APR) is to provide + a free library of C data structures and routines, forming a + system portability layer to as many operating systems as + possible, including Unices, MS Win32, BeOS and OS/2.

+

The project was started as a part of the Apache Web Server almost two years ago, and has been growing ever since. Currently, it is in - use by the Subversion - version control system and - Apache 2.0. + use by the Subversion + version control system and version 2.0 of the + Apache HTTP Server.

-

The Library API

- APR uses ScanDoc to generate all of the API docs in - HTML format. +

The Library API

+

+ APR uses ScanDoc to generate all of the API docs in + HTML format. +

-

How to contribute

- Getting the source code +

How to contribute

+

+ Getting the source code. +

+

+ See the project's guidelines for + more information. +

+ 1.1 apr-site/guidelines.html Index: guidelines.html =================================================================== APR Project Guidelines

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 new-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:

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


Greg Stein
Last modified: Fri Nov 24 16:42:42 PST 2000