doc/developers.txt

   1 ==================
   2 Developing Roundup
   3 ==================
   4
   5 :Version: $Revision: 1.6 $
   6
   7 Note: the intended audience of this document is the developers of the core
   8 Roundup code. If you just wish to alter some behaviour of your Roundup
   9 installation, see `customising roundup`_.
  10
  11 .. contents::
  12
  13 Getting Started
  14 ---------------
  15
  16 Anyone wishing to help in the development of Roundup must read `Roundup's
  17 Design Document`_ and the `implementation notes`_.
  18
  19 All development is coordinated through two resources:
  20
  21 - roundup-dev mailing list at
  22   http://lists.sourceforge.net/mailman/listinfo/roundup-devel
  23 - Sourceforge's issue trackers at
  24   https://sourceforge.net/tracker/?group_id=31577
  25
  26 Small Changes
  27 -------------
  28
  29 Most small changes can be submitted through the Feature tracker, with patches
  30 attached that give context diffs of the affected source.
  31
  32
  33 CVS Access
  34 ----------
  35
  36 To get CVS access, contact richard@users.sourceforge.net.
  37
  38 CVS stuff:
  39
  40 1. to tag a release (eg. the pre-release of 0.5.0)::
  41
  42     cvs tag release-0-5-0-pr1
  43
  44 1. to make a branch (eg. branching for code freeze/release)::
  45
  46     cvs co -d maint-0-5 -r release-0-5-0-pr1
  47     cd maint-0-5
  48     cvs tag -b maint-0-5
  49
  50 2. to check out a branch (eg. the maintenance branch for 0.5.x)::
  51
  52     cvs co -d maint-0-5 -r maint-0-5
  53
  54 3. to merge changes from the maintenance branch to the trunk, in the
  55    directory containing the HEAD checkout::
  56
  57     cvs up -j maint-0-5
  58
  59    though this is highly discouraged, as it generally creates a whole swag
  60    of conflicts :(
  61
  62 Standard tag names:
  63
  64 *release-maj-min-patch[-sub]*
  65   Release of the major.minor.patch release, possibly a beta or pre-release,
  66   in which case *sub* will be one of "b*N*" or "pr*N*".
  67 *maint-maj-min*
  68   Maintenance branch for the major.minor release. Patch releases are tagged in
  69   this branch.
  70
  71 Typically, release happen like this:
  72
  73 1. work progresses in the HEAD branch until milestones are met,
  74 2. a series of beta releases are tagged in the HEAD until the code is
  75    stable enough to freeze,
  76 3. the pre-release is tagged in the HEAD, with the resultant code branched
  77    to the maintenance branch for that release,
  78 4. bugs in the release are patched in the maintenance branch, and the final
  79    and patch releases are tagged there, and
  80 5. further major work happens in the HEAD.
  81
  82 Project Rules
  83 -------------
  84
  85 Mostly the project follows Guido's Style (though naming tends to be a little
  86 relaxed sometimes). In short:
  87
  88 - 80 column width code
  89 - 4-space indentations
  90 - All modules must have a CVS Id line near the top, and a CVS Log at the end
  91
  92 Other project rules:
  93
  94 - New functionality must be documented, even briefly (so at least we know
  95   where there's missing documentation) and changes to tracker configuration
  96   must be logged in the upgrading document.
  97 - subscribe to roundup-checkins to receive checkin notifications from the
  98   other developers with CVS access
  99 - discuss any changes with the other developers on roundup-dev. If nothing
 100   else, this makes sure there's no rude shocks
 101 - write unit tests for changes you make (where possible), and ensure that
 102   all unit tests run before committing changes
 103 - run pychecker over changed code
 104
 105 The administrators of the project reserve the right to boot developers who
 106 consistently check in code which is either broken or takes the codebase in
 107 directions that have not been agreed to.
 108
 109
 110 -----------------
 111
 112 Back to `Table of Contents`_
 113
 114 .. _`Table of Contents`: index.html
 115 .. _`Customising Roundup`: customizing.html
 116 .. _`Roundup's Design Document`: spec.html
 117 .. _`implementation notes`: implementation.html