You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by gs...@locus.apache.org on 2000/11/25 01:54:52 UTC
cvs commit: apr-site guidelines.html index.html
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">
<html>
<head>
- <title>The Apache Portable Run-Time</title>
+ <title>The Apache Portable Runtime</title>
+ </head>
<body>
<table border="0" cellspacing="10" cellpadding="10">
<tr align="left" valign="center">
<td>
<img src="http://www.apache.org/foundation/images/asf_logo.gif"
width="387" height="100" alt="The Apache Software Foundation"></td>
- <td><h1>Portable Run-Time Project</h1></td>
+ <td><h1>Portable Runtime Project</h1></td>
</tr>
</table>
<p>
- 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.
</p>
+ <p>
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 <a href="http://subversion.tigris.org">Subversion</a>
- version control system and
- <a href="http://www.apache.org/httpd.html">Apache 2.0</a>.
+ use by the <a href="http://subversion.tigris.org/">Subversion</a>
+ version control system and version 2.0 of the
+ <a href="http://httpd.apache.org/">Apache HTTP Server</a>.
</p>
- <H3><center>The Library API</center></H3>
- APR uses ScanDoc to generate all of the API docs in
- <a href=docs/index.html>HTML format</a>.
+ <h3>The Library API</h3>
+ <p>
+ APR uses ScanDoc to generate all of the API docs in
+ <a href="docs/index.html">HTML format</a>.
+ </p>
- <H3><center>How to contribute</center></H3>
- <a href=anoncvs.html>Getting</a> the source code
+ <h3>How to contribute</h3>
+ <p>
+ <a href="anoncvs.txt">Getting</a> the source code.
+ </p>
+ <p>
+ See the <a href="guidelines.html">project's guidelines</a> for
+ more information.
+ </p>
+
</body>
</html>
1.1 apr-site/guidelines.html
Index: guidelines.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>APR Project Guidelines</title>
</head>
<body>
<h1>APR Project Guidelines</h1>
<p>
This page describes the procedures and guidelines used by the
APR Project.
</p>
<p>
<i>this is an initial draft</i>
</p>
<h2>Commit Access</h2>
<p>
Commit access will be somewhere between the "lengthy" process of
new-httpd, and the more "open" process in Subversion.
</p>
<p>
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.
</p>
<p>
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.
</p>
<h2>Change Process</h2>
<p>
Most changes (bug fixes and minor, commonsense feature adds) do
not require review. Developers are encouraged to request review
for:
</p>
<ul>
<li>
Large changes affecting many files
</li>
<li>
Changes to interfaces
</li>
<li>
Changes that commit APR to one option out of an exclusive set
</li>
<li>
Any change the developer wants a second (or Nth) opinion on
</li>
</ul>
<p>
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.
</p>
<p>
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.
</p>
<h2>PMC Membership</h2>
<p>
PMC membership is attained through a "consensus approval"
process according to the
<a href="http://dev.apache.org/guidelines.html">standard ASF
guidelines</a>. The voters are the existing PMC members.
</p>
<p>
The general policy is to accept committers who have demonstrated
longevity in dev/doc/admin ability and interest in the APR
project.
</p>
<h2>Decision Making: Consensus and Voting</h2>
<dl>
<dt><strong>NOTE:</strong></dt>
<dd>
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.
</dd>
</dl>
<p>
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.
</p>
<p>
[ gjs: changes can always be reverted, so why a window? and why
is a decision ever "binding"? ]
<br>
[ 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 ]
</p>
<p>
For decisions on which consensus is not reachable or is not
attempted, the group votes, using approval voting:
</p>
<blockquote>
<p>
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:
</p>
<p>
+1 : Yes, agree that the choice should be performed.
<br>
+0 : Seems fine, but I can live without it
<br>
-0 : Doesn't seem right, but I won't argue against it
<br>
-1 : No, I am against this choice being performed.
</p>
</blockquote>
<p>
Choices receiving positive totals may be performed.
</p>
<p>
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.
</p>
<p>
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.
</p>
<h3>Veto as a vote</h3>
<p>
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.
</p>
<h3>Voting Procedure Technicalities</h3>
<p>
Votes are tallied in the <tt>STATUS</tt> file, adjacent to the
action item under vote. All votes must be either sent to the
mailing list or added directly to the <tt>STATUS</tt> file entry
for that action item.
</p>
<hr>
<address><a href="mailto:gstein@lyra.org">Greg Stein</a></address>
<!-- Created: Fri Nov 24 16:27:22 PST 2000 -->
<!-- hhmts start -->
Last modified: Fri Nov 24 16:42:42 PST 2000
<!-- hhmts end -->
</body>
</html>