cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject cvs commit: cocoon-site/src/documentation/content/xdocs/community contrib.xml
Date Fri, 23 Jul 2004 03:42:25 GMT
crossley    2004/07/22 20:42:25

  Modified:    src/documentation/content/xdocs/community contrib.xml
  Log:
  Clarify some of the contribution guidelines. Still needs more work.
  
  Revision  Changes    Path
  1.5       +30 -38    cocoon-site/src/documentation/content/xdocs/community/contrib.xml
  
  Index: contrib.xml
  ===================================================================
  RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/community/contrib.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- contrib.xml	23 Jul 2004 03:13:15 -0000	1.4
  +++ contrib.xml	23 Jul 2004 03:42:24 -0000	1.5
  @@ -91,46 +91,31 @@
     </p>
    </s1>
   
  + <anchor id="contrib"/>
    <s1 title="Contributions of Code and Documentation">
  -  <p>We are starting to use an informal system for accepting contributions to Cocoon.
  -   The process varies depending on whether the contribution is a modification (i.e. patch)
  -   or a fairly standalone item, and whether you have commit access (committers have been
  -   granted access by a vote of confidence, so they are assumed to be trustworthy enough
  -   to make changes directly in CVS. If you submit many good patches, you may be 
  -   nominated as a committer yourself!)</p>
  -
  -  <p>If your contribution requires changing more than a few lines of Cocoon (code
or
  -   documentation), then it counts as a <strong>patch</strong>. If you have
a patch and
  -   would like to see it incorporated into the Cocoon distribution, take note of the Licensing
  -   Requirements listed below, and then read the section 
  -   <link href="#procedure">Procedure for Raising Development Issues</link>
  -  </p>
  -
  -<!--
  -  <p>Otherwise (that is, if it does not require patching or you are not particularly
interested in
  -   having it included in the main distribution), your code and/or
  -   documentation can be listed on the 
  -   <link href="3rdparty.html">Third-Party Contributions</link> page.
  -   The rationale for this split is that core patches may fix important issues, and may

  -   require timely attention if they are not to go
  -   out-of-date and become useless, but other contributions can simply be downloaded and
  -   applied by users who wish to use them.
  +   <p>
  +     If you have a contribution that you would like to see incorporated into
  +     the Cocoon distribution, then please take note of the 
  +     <link href="#license">licensing requirements</link> listed below,
  +     and then read the section 
  +     <link href="#procedure">Procedure for Raising Development Issues</link>.
  +   </p>
  +
  +   <p>
  +     The Cocoon committers have been granted access by a vote of confidence,
  +     so they are assumed to be trustworthy enough to make changes directly in
  +     CVS. Other contributors need to submit a patch via the Cocoon issue
  +     tracker, Bugzilla.
  +   </p>
  +
  +   <p>
  +    Committers must be confident that it would work properly in all operating
  +    systems, it must be documented as appropriate, it must be considered
  +    sufficiently useful and general to go into Cocoon, and it must meet the
  +    Licensing requirements below. Other committers and developers will continue
  +    to enhance it, so don't be surprised if changes are made. Also the PMC may
  +    decide to remove it, if issues are discovered.
     </p>
  --->
  -
  -  <p>A typical contribution (not a patch) may go through the following stages:</p>
  -
  -  <ol>
  -   <li>Posted to cocoon-users with a URL to download it from.</li>
  -<!--   <li>Listed on 3rdparty.html by a maintainer. [No requirements, other than
relevance (at the moment).]</li> -->
  -   <li>Inclusion into the <code>contrib</code> directory,
  -    which is for 3rd-party contributions that have been tested, but are not necessarily
  -    mature enough or general enough for the main distribution. [Must be tested at least
as
  -    specified below. See also Licensing Requirements below.]</li>
  -   <li>Inclusion into the main distribution. [Committers must be confident that it
should work properly in 
  -    most/all environments, it must be documented as appropriate, and it must be considered
sufficiently
  -    useful and general to go into Cocoon. See also  Licensing Requirements below].</li>
  -  </ol>
     
     <s2 title="Testing Requirements for Cocoon Contrib and Distribution">
      <p>All new code should be tested under at least the following servlet engines:</p>
  @@ -164,6 +149,7 @@
     </p>
    </s2>
   
  + <anchor id="license"/>
    <s2 title="Licensing Requirements for the Cocoon Distribution">
     <p>To avoid legal problems, the Apache Project Management Committee (PMC) have
agreed on
      a policy for under what licensing code can be accepted into Apache projects:</p>
  @@ -325,6 +311,12 @@
   
    <anchor id="procedure"/>
    <s1 title="Procedure for Raising Development Issues">
  +  <p>Documentation contributions can usually be added directly to the
  +    issue tracker. First read the 
  +    <link href="#contrib">contribution notes</link> above, then follow the
  +    <link href="http://cocoon.apache.org/2.1/howto/index.html#Contribution">howto
documents</link>
  +    about patching and about using Bugzilla.
  +  </p>
     <p>
      There are two methods for discussing development and submitting patches.
      So that everyone can be productive, it is important to know which method
  
  
  

Mime
View raw message