+ <sect2 id="cvsaccess"><title>Access to CVS</title>
+ <para>
+ The project's CVS repository is hosted on
+ <ulink url="http://sourceforge.net/">SourceForge.</ulink>
+ Please refer to the chapters 6 and 7 in
+ <ulink url="http://sourceforge.net/docman/?group_id=1">SF's site
+ documentation</ulink> for the technical access details for your
+ operating system. For historical reasons, the CVS server is
+ called <literal>cvs.ijbswa.sourceforge.net</literal>, the repository is
+ called <literal>ijbswa</literal>, and the source tree module is called
+ <literal>current</literal>.
+ </para>
+ </sect2>
+
+ <sect2 id="cvsbranches">
+ <title>Branches</title>
+ <para>
+ Within the CVS repository, there are modules and branches. As
+ mentioned, the sources are in the <literal>current</literal>
+ <quote>module</quote>. Other modules are present for platform specific
+ issues. There is a webview of the CVS hierarchy at <ulink
+ url="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/">http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</ulink>,
+ which might help with visualizing how these pieces fit together.
+ </para>
+ <para>
+ Branches are used to fork a sub-development path from the main trunk.
+ Within the <literal>current</literal> module where the sources are, there
+ 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).
+ 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>
+ </sect2>
+
+ <sect2 id="cvscommit"><title>CVS Commit Guidelines</title>
+ <para>
+ The source tree is the heart of every software project. Every effort must
+ be made to ensure that it is readable, compilable and consistent at all
+ times. There are differing guidelines for the stable branch and the
+ main development trunk, and we ask anyone with CVS access to strictly
+ adhere to the following guidelines:
+ </para>
+
+ <para>
+ Basic Guidelines, for all branches:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem><para>
+ Never (read: <emphasis>never, ever</emphasis>) be tempted to commit
+ that small change without testing it thoroughly first. When we're
+ close to a public release, ask a fellow developer to review your
+ changes.
+ </para></listitem>
+ <listitem><para>
+ Your commit message should give a concise overview of <emphasis>what you
+ changed</emphasis> (no big details) and <emphasis>why you changed it</emphasis>
+ Just check previous messages for good examples.
+ </para></listitem>
+ <listitem><para>
+ Don't use the same message on multiple files, unless it equally applies to
+ all those files.
+ </para></listitem>
+ <listitem><para>
+ If your changes span multiple files, and the code won't recompile unless
+ all changes are committed (e.g. when changing the signature of a function),
+ then commit all files one after another, without long delays in between.
+ If necessary, prepare the commit messages in advance.
+ </para></listitem>
+ <listitem><para>
+ Before changing things on CVS, make sure that your changes are in line
+ with the team's general consensus on what should be done.
+ </para></listitem>
+ <listitem>
+ <para>
+ Note that near a major public release, we get more cautious.
+ There is always the possibility to submit a patch to the <ulink
+ url="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse">patch
+ tracker</ulink> instead.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ 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>
+ <itemizedlist>
+ <listitem><para>
+ Do <emphasis>not commit anything</emphasis> into the stable branch,
+ 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>
+ <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>
+ Alternately, proposed changes can be submitted as patches to the patch tracker on
+ Sourceforge first: <ulink
+ url="http://sourceforge.net/tracker/?group_id=11118&atid=311118">http://sourceforge.net/tracker/?group_id=11118&atid=311118</ulink>.
+ Then ask for peer review.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 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>
+ <para>
+ Do not even think about anything except bugfixes. No new features!
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </sect2>
+
+<!--
+ This sounds vague, dated, and out of step with current development style.
+ Removing 09/03/02, HB.
+
+ <sect2 id="cvswhenask"><title>Discussing Changes First</title>
+ <para>
+ We don't have a formal policy for the development branch, just use
+ common sense. Hints: If it is..
+ <orderedlist numeration="arabic">
+ <listitem><para>
+ ..a bug-fix / clean-up / cosmetic thing: shoot
+ </para></listitem>
+ <listitem><para>
+ ..a new feature that can be turned off: shoot
+ </para></listitem>
+ <listitem><para>
+ ..a clear improvement w/o side effects on other parts of the code: shoot
+ </para></listitem>
+ <listitem><para>
+ ..a matter of taste: <ulink url="mailto:developers@privoxy.org">ask the list</ulink>
+ </para></listitem>
+ <listitem><para>
+ ..a major redesign of some part of the code: <ulink url="mailto:developers@privoxy.org">ask
+ the list</ulink>
+ </para></listitem>
+ </orderedlist>
+ </para>
+ <para>
+ Note that near a major public release, we get a bit more cautious - if
+ unsure, it doesn't hurt to ask first. There is always the possibility
+ to submit a patch to the <ulink
+ url="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse">patches
+ tracker</ulink> instead.
+ </para>
+ </sect2>
+ -->
+ </sect1>