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
