Mercurial > p > roundup > code
comparison doc/developers.txt @ 1356:83f33642d220 maint-0.5
[[Metadata associated with this commit was garbled during conversion from CVS
to Subversion.]]
| author | Richard Jones <richard@users.sourceforge.net> |
|---|---|
| date | Thu, 09 Jan 2003 22:59:22 +0000 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| 1242:3d0158c8c32b | 1356:83f33642d220 |
|---|---|
| 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 |