>The CVS Repository</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.64
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Privoxy Developer Manual"
><DIV
CLASS="NAVHEADER"
><TABLE
+SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
VALIGN="bottom"
><A
HREF="introduction.html"
+ACCESSKEY="P"
>Prev</A
></TD
><TD
VALIGN="bottom"
><A
HREF="documentation.html"
+ACCESSKEY="N"
>Next</A
></TD
></TR
><H1
CLASS="SECT1"
><A
-NAME="CVS"
->2. The CVS Repository</A
-></H1
+NAME="CVS">2. The CVS Repository</H1
><P
> If you intend to help us with programming, documentation or packaging
you will need write access to our holy grail, the CVS repository.
><H2
CLASS="SECT2"
><A
-NAME="CVSACCESS"
->2.1. Access to CVS</A
-></H2
+NAME="CVSACCESS">2.1. Access to CVS</H2
><P
> The project's CVS repository is hosted on
<A
><H2
CLASS="SECT2"
><A
-NAME="CVSCOMMIT"
->2.2. CVS Commit Guideline</A
-></H2
+NAME="CVSBRANCHES">2.2. Branches</H2
+><P
+> Within the CVS repository, there are modules and branches. As
+ mentioned, the sources are in the <TT
+CLASS="LITERAL"
+>current</TT
+>
+ <SPAN
+CLASS="QUOTE"
+>"module"</SPAN
+>. Other modules are present for platform specific
+ issues. There is a webview of the CVS hierarchy at <A
+HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/"
+TARGET="_top"
+>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</A
+>,
+ which might help with visualizing how these pieces fit together.
+ </P
+><P
+> Branches are used to fork a sub-development path from the main trunk.
+ Within the <TT
+CLASS="LITERAL"
+>current</TT
+> module where the sources are, there
+ is always at least one <SPAN
+CLASS="QUOTE"
+>"branch"</SPAN
+> 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
+ <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>only used for bugfixes</I
+></SPAN
+>, which have had prior
+ testing before being committed to CVS. (See <A
+HREF="newrelease.html#VERSIONNUMBERS"
+>Version Numbers</A
+> below for details on
+ versioning.)
+ </P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="CVSCOMMIT">2.3. CVS Commit Guidelines</H2
><P
> 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. We therefore ask anyone with CVS access to strictly adhere to the
- following guidelines:
- <P
+ 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:
+ </P
+><P
+> Basic Guidelines, for all branches:
+ </P
+><P
+> <P
></P
><UL
><LI
><P
-> Never (read: <I
+> Never (read: <SPAN
+CLASS="emphasis"
+><I
CLASS="EMPHASIS"
>never, ever</I
+></SPAN
>) 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
></LI
><LI
><P
-> Your commit message should give a concise overview of <I
+> Your commit message should give a concise overview of <SPAN
+CLASS="emphasis"
+><I
CLASS="EMPHASIS"
>what you
changed</I
-> (no big details) and <I
+></SPAN
+> (no big details) and <SPAN
+CLASS="emphasis"
+><I
CLASS="EMPHASIS"
>why you changed it</I
+></SPAN
>
Just check previous messages for good examples.
</P
><LI
><P
> If your changes span multiple files, and the code won't recompile unless
- all changes are commited (e.g. when changing the signature of a function),
- then commit all files one after another, without long delays in beween.
+ 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.
</P
></LI
><LI
><P
> Before changing things on CVS, make sure that your changes are in line
- with the team's general consensus on what should be done (see below).
+ with the team's general consensus on what should be done.
+ </P
+></LI
+><LI
+><P
+> Note that near a major public release, we get more cautious.
+ There is always the possibility to submit a patch to the <A
+HREF="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
+TARGET="_top"
+>patch
+ tracker</A
+> instead.
</P
></LI
></UL
>
</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="CVSWHENASK"
->2.3. Discussing Changes First</A
-></H2
><P
-> We don't have a too formal policy on this, just use common sense. Hints: If it is..
- <P
+> 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):
+ </P
+><P
+> <P
></P
-><OL
-TYPE="1"
+><UL
><LI
><P
-> ..a bugfix / clean-up / cosmetic thing: shoot
- </P
+> Do <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>not commit anything</I
+></SPAN
+> 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.
+ </P
></LI
><LI
><P
-> ..a new feature that can be turned off: shoot
- </P
+> Where possible, bugfixes and changes should be tested in the main
+ development trunk first. There may be occasions where this is not
+ feasible, though.
+ </P
></LI
><LI
><P
-> ..a clear improvement w/o side effects on other parts of the code: shoot
- </P
+> Alternately, proposed changes can be submitted as patches to the patch tracker on
+ Sourceforge first: <A
+HREF="http://sourceforge.net/tracker/?group_id=11118&atid=311118"
+TARGET="_top"
+>http://sourceforge.net/tracker/?group_id=11118&atid=311118</A
+>.
+ Then ask for peer review.
+ </P
></LI
><LI
><P
-> ..a matter of taste: <A
-HREF="mailto:developers@privoxy.org"
-TARGET="_top"
->ask the list</A
->
- </P
+> Do not commit <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>anything</I
+></SPAN
+> 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.
+ </P
></LI
><LI
><P
-> ..a major redesign of some part of the code: <A
-HREF="mailto:developers@privoxy.org"
-TARGET="_top"
->ask
- the list</A
->
- </P
+> Do not even think about anything except bugfixes. No new features!
+ </P
></LI
-></OL
+></UL
>
</P
-><P
-> 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 <A
-HREF="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
-TARGET="_top"
->patches
- tracker</A
-> instead.
- </P
></DIV
></DIV
><DIV
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
VALIGN="top"
><A
HREF="introduction.html"
+ACCESSKEY="P"
>Prev</A
></TD
><TD
VALIGN="top"
><A
HREF="index.html"
+ACCESSKEY="H"
>Home</A
></TD
><TD
VALIGN="top"
><A
HREF="documentation.html"
+ACCESSKEY="N"
>Next</A
></TD
></TR
projects / privoxy.git / blobdiff