Mention tested stable branch fixes in main trunk, as alternate to posting

[privoxy.git] / doc / source / developer-manual.sgml

diff --git a/doc/source/developer-manual.sgml b/doc/source/developer-manual.sgml
index b8d762a..282dd72 100644 (file)
--- a/doc/source/developer-manual.sgml
+++ b/doc/source/developer-manual.sgml
@@ -23,7 +23,7 @@
                 This file belongs into
                 ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
                 
- $Id: developer-manual.sgml,v 2.1 2002/07/29 22:08:40 jongfoster Exp $
+ $Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $
 
  Copyright (C) 2001, 2002 Privoxy Developers <developers@privoxy.org>
  See LICENSE.
@@ -48,7 +48,7 @@
     </pubdate>
 
 
-    <pubdate>$Id: developer-manual.sgml,v 1.46.2.8 2002/08/17 00:16:10 hal9 Exp $</pubdate>
+    <pubdate>$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $</pubdate>
 
 <!--
 
@@ -189,11 +189,12 @@ Hal.
        is always at least one <quote>branch</quote> from the main trunk
        devoted to a stable release series. The main trunk is where active
        development takes place for the next stable series (e.g. 3.2.x).
-       So just prior to each stable series (e.g. 3.0.x), a branch is created
-       just for stable series releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc).
-       Once the initial stable release of any stable branch has taken place,
-       this branch is <emphasis>only used for bugfixes</emphasis>, which have
-       had prior testing before being committed to CVS. (See <link
+       And for testing bugfixes for the stable series. Just prior to each
+       stable series (e.g. 3.0.x), a branch is created just for stable series
+       releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc). Once the initial stable
+       release of any stable branch has taken place, this branch is
+       <emphasis>only used for bugfixes</emphasis>, which have had prior
+       testing before being committed to CVS. (See <link
        linkend="versionnumbers">Version Numbers</link> below for details on
        versioning.)
      </para>
@@ -250,10 +251,10 @@ Hal.
       </para>
       
       <para>
-       Stable branches are handled with more care, especially after the 
-       initial *.*.0 release, and we are just in bugfix mode. In addition to 
-       the above, the below applies only to the stable branch (currently the 
-       v_3_0_branchpoint branch):
+       Stable branches are handled with decidedly more care, especially after
+       the initial *.*.0 release, and we are just in bugfix mode. In addition
+       to the above, the below applies only to the stable branch (currently
+       the v_3_0_branchpoint branch):
       </para>
       
       <para>
@@ -263,20 +264,29 @@ Hal.
           unless immediately before a new release! There needs to be testing 
           done before it hits CVS, and to ensure that all changes are
           appropriate just to fix whatever the problem is.
-        </para></listitem>
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Where possible, bugfixes and changes should be tested in the main 
+         development trunk first. There may be occasions where this is not 
+         feasible, though.
+        </para>
+       </listitem> 
        <listitem>
         <para>
-          Submit any proposed changes as patches first to the patch tracker on 
-          Sourceforge: <ulink url="http://sourceforge.net/tracker/?group_id=11118&#38;atid=311118">http://sourceforge.net/tracker/?group_id=11118&#38;atid=311118</ulink>.
-          Then ask for peer review.
+          Alternately, proposed changes can be submitted as patches to the patch tracker on 
+          Sourceforge first: <ulink
+          url="http://sourceforge.net/tracker/?group_id=11118&#38;atid=311118">http://sourceforge.net/tracker/?group_id=11118&#38;atid=311118</ulink>.
+          Then ask for peer review. 
         </para>
        </listitem> 
         <listitem>
          <para>
-           Do not commit <emphasis>anything</emphasis> unless your patches
-           been well tested first, by other members of the project, 
-           and has prior approval of the project leaders or consensus of the
-           devel list.
+           Do not commit <emphasis>anything</emphasis> unless your proposed
+           changes have been well tested first, by other members of the
+           project, and have prior approval of the project leaders or consensus
+           of the devel list.
          </para>
         </listitem> 
         <listitem>
@@ -1833,7 +1843,7 @@ static void unload_re_filterfile( void *f ) { ... }</programlisting>
 
     <para><emphasis>Example for file comments:</emphasis></para>
 <programlisting>
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.46.2.8 2002/08/17 00:16:10 hal9 Exp $";
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $";
 /*********************************************************************
  *
  * File        :  $S<!-- Break CVS Substitution -->ource$
@@ -1893,7 +1903,7 @@ const char FILENAME_h_rcs[] = FILENAME_H_VERSION;
 <programlisting>
 #ifndef _FILENAME_H
 #define _FILENAME_H
-#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.46.2.8 2002/08/17 00:16:10 hal9 Exp $"
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $"
 /*********************************************************************
  *
  * File        :  $S<!-- Break CVS Substitution -->ource$
@@ -2987,6 +2997,11 @@ at sourceforge. Three simple steps:
   Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 
   $Log: developer-manual.sgml,v $
+  Revision 2.2  2002/09/04 01:55:44  hal9
+  Migrating developer manual, and related sgml files from 3.0. Add additional
+  commentary on cvs, versioning, stable branches, and how to handle stable
+  branches in cvs.
+
   Revision 1.46.2.8  2002/08/17 00:16:10  hal9
   Add note on updating webserver for User-manual/CGI editor, which is version
   dependent (and different from main UM link).