| [740] | 1 | ===================================
|
|---|
| 2 | Notes for contributing to testtools
|
|---|
| 3 | ===================================
|
|---|
| 4 |
|
|---|
| 5 | Coding style
|
|---|
| 6 | ------------
|
|---|
| 7 |
|
|---|
| 8 | In general, follow PEP 8 <http://www.python.org/dev/peps/pep-0008/>.
|
|---|
| 9 |
|
|---|
| 10 | For consistency with the standard library's ``unittest`` module, method names
|
|---|
| 11 | are generally ``camelCase``.
|
|---|
| 12 |
|
|---|
| 13 | testtools supports Python 2.4 and later, so avoid any 2.5-only features like
|
|---|
| 14 | the ``with`` statement.
|
|---|
| 15 |
|
|---|
| 16 |
|
|---|
| 17 | Copyright assignment
|
|---|
| 18 | --------------------
|
|---|
| 19 |
|
|---|
| 20 | Part of testtools raison d'etre is to provide Python with improvements to the
|
|---|
| 21 | testing code it ships. For that reason we require all contributions (that are
|
|---|
| 22 | non-trivial) to meet one of the following rules:
|
|---|
| 23 |
|
|---|
| 24 | - be inapplicable for inclusion in Python.
|
|---|
| 25 | - be able to be included in Python without further contact with the
|
|---|
| 26 | contributor.
|
|---|
| 27 | - be copyright assigned to Jonathan M. Lange.
|
|---|
| 28 |
|
|---|
| 29 | Please pick one of these and specify it when contributing code to testtools.
|
|---|
| 30 |
|
|---|
| 31 |
|
|---|
| 32 | Licensing
|
|---|
| 33 | ---------
|
|---|
| 34 |
|
|---|
| 35 | All code that is not copyright assigned to Jonathan M. Lange (see Copyright
|
|---|
| 36 | Assignment above) needs to be licensed under the MIT license that testtools
|
|---|
| 37 | uses, so that testtools can ship it.
|
|---|
| 38 |
|
|---|
| 39 |
|
|---|
| 40 | Testing
|
|---|
| 41 | -------
|
|---|
| 42 |
|
|---|
| 43 | Please write tests for every feature. This project ought to be a model
|
|---|
| 44 | example of well-tested Python code!
|
|---|
| 45 |
|
|---|
| 46 | Take particular care to make sure the *intent* of each test is clear.
|
|---|
| 47 |
|
|---|
| 48 | You can run tests with ``make check``, or by running ``./run-tests`` directly.
|
|---|
| 49 |
|
|---|
| 50 |
|
|---|
| 51 | Source layout
|
|---|
| 52 | -------------
|
|---|
| 53 |
|
|---|
| 54 | The top-level directory contains the ``testtools/`` package directory, and
|
|---|
| 55 | miscellaneous files like README and setup.py.
|
|---|
| 56 |
|
|---|
| 57 | The ``testtools/`` directory is the Python package itself. It is separated
|
|---|
| 58 | into submodules for internal clarity, but all public APIs should be âpromotedâ
|
|---|
| 59 | into the top-level package by importing them in ``testtools/__init__.py``.
|
|---|
| 60 | Users of testtools should never import a submodule, they are just
|
|---|
| 61 | implementation details.
|
|---|
| 62 |
|
|---|
| 63 | Tests belong in ``testtools/tests/``.
|
|---|
| 64 |
|
|---|
| 65 |
|
|---|
| 66 | Commiting to trunk
|
|---|
| 67 | ------------------
|
|---|
| 68 |
|
|---|
| 69 | Testtools is maintained using bzr, with its trunk at lp:testtools. This gives
|
|---|
| 70 | every contributor the ability to commit their work to their own branches.
|
|---|
| 71 | However permission must be granted to allow contributors to commit to the trunk
|
|---|
| 72 | branch.
|
|---|
| 73 |
|
|---|
| 74 | Commit access to trunk is obtained by joining the testtools-devs Launchpad
|
|---|
| 75 | team. Membership in this team is contingent on obeying the testtools
|
|---|
| 76 | contribution policy, including assigning copyright of all the work one creates
|
|---|
| 77 | and places in trunk to Jonathan Lange.
|
|---|
| 78 |
|
|---|
| 79 |
|
|---|
| 80 | Code Review
|
|---|
| 81 | -----------
|
|---|
| 82 |
|
|---|
| 83 | All code must be reviewed before landing on trunk. The process is to create a
|
|---|
| 84 | branch in launchpad, and submit it for merging to lp:testtools. It will then
|
|---|
| 85 | be reviewed before it can be merged to trunk. It will be reviewed by someone:
|
|---|
| 86 |
|
|---|
| 87 | * not the author
|
|---|
| 88 | * a committer (member of the testtools-devs team)
|
|---|
| 89 |
|
|---|
| 90 | As a special exception, while the testtools committers team is small and prone
|
|---|
| 91 | to blocking, a merge request from a committer that has not been reviewed after
|
|---|
| 92 | 24 hours may be merged by that committer. When the team is larger this policy
|
|---|
| 93 | will be revisited.
|
|---|
| 94 |
|
|---|
| 95 | Code reviewers should look for the quality of what is being submitted,
|
|---|
| 96 | including conformance with this HACKING file.
|
|---|
| 97 |
|
|---|
| 98 | Changes which all users should be made aware of should be documented in NEWS.
|
|---|
| 99 |
|
|---|
| 100 |
|
|---|
| 101 | NEWS management
|
|---|
| 102 | ---------------
|
|---|
| 103 |
|
|---|
| 104 | The file NEWS is structured as a sorted list of releases. Each release can have
|
|---|
| 105 | a free form description and more or more sections with bullet point items.
|
|---|
| 106 | Sections in use today are 'Improvements' and 'Changes'. To ease merging between
|
|---|
| 107 | branches, the bullet points are kept alphabetically sorted. The release NEXT is
|
|---|
| 108 | permanently present at the top of the list.
|
|---|
| 109 |
|
|---|
| 110 |
|
|---|
| 111 | Release tasks
|
|---|
| 112 | -------------
|
|---|
| 113 |
|
|---|
| 114 | 1. Choose a version number, say X.Y.Z
|
|---|
| 115 | 1. Branch from trunk to testtools-X.Y.Z
|
|---|
| 116 | 1. In testtools-X.Y.Z, ensure __init__ has version X.Y.Z.
|
|---|
| 117 | 1. Replace NEXT in NEWS with the version number X.Y.Z, adjusting the reST.
|
|---|
| 118 | 1. Possibly write a blurb into NEWS.
|
|---|
| 119 | 1. Replace any additional references to NEXT with the version being
|
|---|
| 120 | released. (should be none).
|
|---|
| 121 | 1. Commit the changes.
|
|---|
| 122 | 1. Tag the release, bzr tag testtools-X.Y.Z
|
|---|
| 123 | 1. Create a source distribution and upload to pypi ('make release').
|
|---|
| 124 | 1. Make sure all "Fix committed" bugs are in the 'next' milestone on
|
|---|
| 125 | Launchpad
|
|---|
| 126 | 1. Rename the 'next' milestone on Launchpad to 'X.Y.Z'
|
|---|
| 127 | 1. Create a release on the newly-renamed 'X.Y.Z' milestone
|
|---|
| 128 | 1. Upload the tarball and asc file to Launchpad
|
|---|
| 129 | 1. Merge the release branch testtools-X.Y.Z into trunk. Before the commit,
|
|---|
| 130 | add a NEXT heading to the top of NEWS and bump the version in __init__.py.
|
|---|
| 131 | Push trunk to Launchpad
|
|---|
| 132 | 1. If a new series has been created (e.g. 0.10.0), make the series on Launchpad.
|
|---|
| 133 | 1. Make a new milestone for the *next release*.
|
|---|
| 134 | 1. During release we rename NEXT to $version.
|
|---|
| 135 | 1. We call new milestones NEXT.
|
|---|
