--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/developers.txt	Thu Jan 09 22:59:22 2003 +0000
@@ -0,0 +1,117 @@
+==================
+Developing Roundup
+==================
+
+:Version: $Revision: 1.6 $
+
+Note: the intended audience of this document is the developers of the core
+Roundup code. If you just wish to alter some behaviour of your Roundup
+installation, see `customising roundup`_.
+
+.. contents::
+
+Getting Started
+---------------
+
+Anyone wishing to help in the development of Roundup must read `Roundup's
+Design Document`_ and the `implementation notes`_.
+
+All development is coordinated through two resources:
+
+- roundup-dev mailing list at
+  http://lists.sourceforge.net/mailman/listinfo/roundup-devel
+- Sourceforge's issue trackers at
+  https://sourceforge.net/tracker/?group_id=31577
+
+Small Changes
+-------------
+
+Most small changes can be submitted through the Feature tracker, with patches
+attached that give context diffs of the affected source.
+
+
+CVS Access
+----------
+
+To get CVS access, contact richard@users.sourceforge.net.
+
+CVS stuff:
+
+1. to tag a release (eg. the pre-release of 0.5.0)::
+
+    cvs tag release-0-5-0-pr1
+
+1. to make a branch (eg. branching for code freeze/release)::
+
+    cvs co -d maint-0-5 -r release-0-5-0-pr1
+    cd maint-0-5 
+    cvs tag -b maint-0-5
+
+2. to check out a branch (eg. the maintenance branch for 0.5.x)::
+
+    cvs co -d maint-0-5 -r maint-0-5
+
+3. to merge changes from the maintenance branch to the trunk, in the
+   directory containing the HEAD checkout::
+
+    cvs up -j maint-0-5
+
+   though this is highly discouraged, as it generally creates a whole swag
+   of conflicts :(
+
+Standard tag names:
+
+*release-maj-min-patch[-sub]*
+  Release of the major.minor.patch release, possibly a beta or pre-release,
+  in which case *sub* will be one of "b*N*" or "pr*N*".
+*maint-maj-min*
+  Maintenance branch for the major.minor release. Patch releases are tagged in
+  this branch.
+
+Typically, release happen like this:
+
+1. work progresses in the HEAD branch until milestones are met,
+2. a series of beta releases are tagged in the HEAD until the code is
+   stable enough to freeze,
+3. the pre-release is tagged in the HEAD, with the resultant code branched
+   to the maintenance branch for that release,
+4. bugs in the release are patched in the maintenance branch, and the final
+   and patch releases are tagged there, and
+5. further major work happens in the HEAD.
+
+Project Rules
+-------------
+
+Mostly the project follows Guido's Style (though naming tends to be a little
+relaxed sometimes). In short:
+
+- 80 column width code
+- 4-space indentations
+- All modules must have a CVS Id line near the top, and a CVS Log at the end
+
+Other project rules:
+
+- New functionality must be documented, even briefly (so at least we know
+  where there's missing documentation) and changes to tracker configuration
+  must be logged in the upgrading document.
+- subscribe to roundup-checkins to receive checkin notifications from the
+  other developers with CVS access
+- discuss any changes with the other developers on roundup-dev. If nothing
+  else, this makes sure there's no rude shocks
+- write unit tests for changes you make (where possible), and ensure that
+  all unit tests run before committing changes
+- run pychecker over changed code
+
+The administrators of the project reserve the right to boot developers who
+consistently check in code which is either broken or takes the codebase in
+directions that have not been agreed to.
+
+
+-----------------
+
+Back to `Table of Contents`_
+
+.. _`Table of Contents`: index.html
+.. _`Customising Roundup`: customizing.html
+.. _`Roundup's Design Document`: spec.html
+.. _`implementation notes`: implementation.html