apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gst...@locus.apache.org
Subject cvs commit: apr-site guidelines.html index.html
Date Sat, 25 Nov 2000 00:54:52 GMT
gstein      00/11/24 16:54:51

  Modified:    .        index.html
  Added:       .        guidelines.html
  *) 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 @@
  -  <title>The Apache Portable Run-Time</title>
  +  <title>The Apache Portable Runtime</title>
  + </head>
     <table border="0" cellspacing="10" cellpadding="10">
      <tr align="left" valign="center">
        <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>
  -  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>
     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>.
  -  <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>
  1.1                  apr-site/guidelines.html
  Index: guidelines.html
      <title>APR Project Guidelines</title>
      <h1>APR Project Guidelines</h1>
        This page describes the procedures and guidelines used by the
        APR Project.
        <i>this is an initial draft</i>
      <h2>Commit Access</h2>
        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.
      <h2>Change Process</h2>
        Most changes (bug fixes and minor, commonsense feature adds) do
        not require review.  Developers are encouraged to request review
  	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.
      <h2>PMC Membership</h2>
        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.
        The general policy is to accept committers who have demonstrated
        longevity in dev/doc/admin ability and interest in the APR
      <h2>Decision Making: Consensus and Voting</h2>
  	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.
      <h3>Veto as a vote</h3>
        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.
      <h3>Voting Procedure Technicalities</h3>
        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.
      <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 -->

View raw message