You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by vg...@apache.org on 2005/09/27 17:42:32 UTC

svn commit: r291978 - /cocoon/site/src/documentation/content/xdocs/guidelines.xml

Author: vgritsenko
Date: Tue Sep 27 08:42:27 2005
New Revision: 291978

URL: http://svn.apache.org/viewcvs?rev=291978&view=rev
Log:
Tweaks:
Remove 'Contributors' role
Weaken code guidelines requirement
Remove (almost) duplicate section about branches
Mention maintenance branches


Modified:
    cocoon/site/src/documentation/content/xdocs/guidelines.xml   (contents, props changed)

Modified: cocoon/site/src/documentation/content/xdocs/guidelines.xml
URL: http://svn.apache.org/viewcvs/cocoon/site/src/documentation/content/xdocs/guidelines.xml?rev=291978&r1=291977&r2=291978&view=diff
==============================================================================
--- cocoon/site/src/documentation/content/xdocs/guidelines.xml (original)
+++ cocoon/site/src/documentation/content/xdocs/guidelines.xml Tue Sep 27 08:42:27 2005
@@ -1,6 +1,10 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN"
 "document-v12.dtd">
+
+<!--
+  - $Id$
+  -->
 <document>
   <header>
     <title>Apache Cocoon Project Guidelines - DRAFT</title>
@@ -45,23 +49,15 @@
         they become a developer.</p>
       </section>
 
-      <section id="Contributors">
-        <title>Contributors</title>
-
-        <p>Contributors are the people who write code or documentation patches
-        or contribute positively to the project in other ways. Such 
-        volunteer contributions are recognized in various ways.
-        </p>
-      </section>
-
       <section id="committers">
         <title>Committers</title>
 
-        <p>Contributors who give frequent and valuable contributions to a
-        subproject of the Project and demonstrate commitment, may be asked
-        to become a <em>&#34;Committer&#34;</em> for that subproject.
-        A Committer has write access to the source code repository and 
-        voting rights enabling them to affect the future of the subproject.
+        <p>Users or Developers (further: Contributors) who give frequent and
+        valuable contributions to a subproject of the Project and demonstrate
+        commitment, may be asked to become a <em>&#34;Committer&#34;</em> for
+        that subproject. A Committer has write access to the source code
+        repository and voting rights enabling them to affect the future of the
+        subproject.
         </p>
 
 <!-- NOTE: See the recent thread about committer proposal and voting:
@@ -164,9 +160,9 @@
       </section>
 
       <section>
-        <title>CVS Commit Lists</title>
+        <title>SCM Commit Lists</title>
 
-        <p>The cvs list is where all Subversion (SVN) code commit messages are 
+        <p>The SCM list is where all Subversion (SVN) code commit messages are 
         automatically sent.
         All committers are required to subscribe to this list so that they can
         stay aware of changes to the repository.</p>
@@ -493,8 +489,8 @@
 
         <ol>
           <li>Every committer has the right to revolution. Anyone can
-          establish a branch or seperate whiteboard directory in which to
-          experiment with new code seperate from the main trunk. The only
+          establish a branch or separate whiteboard directory in which to
+          experiment with new code independently from the main trunk. The only
           responsibility a committer has when they do this is to announce
           their short and long range plans, and allow others who want to help
           to do so. Committers working on a revolutionary branch have the
@@ -519,6 +515,11 @@
           Evolutionary work is important and should not stop as it is always
           unclear when any particular revolution will be ready for prime time
           or whether it will be officially accepted.</li>
+
+          <li>Maintenance branches can be created to provide support for
+          the released versions of the software. Maintenance branches
+          should receive only bugfixes to the originally released software,
+          and shall be used to create patch releases.</li>
         </ol>
       </section>
     </section>
@@ -531,9 +532,10 @@
       have write access to these repositories. Everyone has read access via
       anonymous SVN.</p>
 
-      <p>All Java Language source code in the repository must be written in
-      conformance to the &#34;Code Conventions for the Java Programming
-      Language as published by Sun.</p>
+      <p>All Java Language source code in the repository should preferably be
+      written in conformance to the &#34;Code Conventions for the Java
+      Programming Language as published by Sun. Use of tab character for
+      indenting is prohibited.</p>
 
       <section>
         <title>License</title>
@@ -547,35 +549,14 @@
         <title>Status Files</title>
 
         <p>Each of the Project&#39;s active source code repositories contain a
-        file named STATUS which is used to keep track of the agenda and plans
+        file named <code>STATUS</code>, or <code>status.xml</code> which is used
+        to keep track of the agenda and plans
         for work within that repository. The status file includes information
         about release plans, a summary of code changes committed since the
         last release, a list of proposed changes that are under discussion,
         brief notes about items that individual volunteers are working on or
         want discussion about, and anything else that may be useful to help
         the group track progress.</p>
-
-        <p>The active status files are automatically posted to the Developer
-        mailing lists three times per week.</p>
-      </section>
-
-      <section>
-        <title>Branches</title>
-
-        <p>Groups are allowed to create a branch for release cycles, etc. They
-        are expected to merge completely back with the main branch as soon as
-        their release cycle is complete.</p>
-
-        <p>A branch is considered &#34;evolutionary&#34; by lazy consensus.
-        Upon any dispute (binding veto), a branch must be converted to
-        &#34;revolutionary&#34; status, and must be assigned a working name
-        that does not imply it will be the next version of the product. Once a
-        release plan for the branch has been approved, and the proposed
-        release is ready for testing, it may be assigned a version name
-        reflecting it is a product release candidate, and merged back with the
-        main branch, as appropriate to the circumstances. Any branch,
-        &#34;evolutionary&#34; or &#34;revolutionary&#34;, shall meet the same
-        standard for release approval.</p>
       </section>
 
       <section>

Propchange: cocoon/site/src/documentation/content/xdocs/guidelines.xml
------------------------------------------------------------------------------
    svn:keywords = Id