summaryrefslogtreecommitdiff
path: root/lib/testtools/HACKING
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2011-08-27 16:07:25 +0200
committerJelmer Vernooij <jelmer@samba.org>2011-08-27 16:07:25 +0200
commitdd56d27d74ad702803818237a2732d1e99b14da1 (patch)
treecc926bb235a7f96c1bc8e5a3644d19d306a719c2 /lib/testtools/HACKING
parentef3bb09db6f6985eac82f4e80259c44be6ca8c20 (diff)
downloadsamba-dd56d27d74ad702803818237a2732d1e99b14da1.tar.gz
samba-dd56d27d74ad702803818237a2732d1e99b14da1.tar.bz2
samba-dd56d27d74ad702803818237a2732d1e99b14da1.zip
testtools: Update to latest upstream snapshot.
Diffstat (limited to 'lib/testtools/HACKING')
-rw-r--r--lib/testtools/HACKING135
1 files changed, 0 insertions, 135 deletions
diff --git a/lib/testtools/HACKING b/lib/testtools/HACKING
deleted file mode 100644
index e9ece73585..0000000000
--- a/lib/testtools/HACKING
+++ /dev/null
@@ -1,135 +0,0 @@
-===================================
-Notes for contributing to testtools
-===================================
-
-Coding style
-------------
-
-In general, follow PEP 8 <http://www.python.org/dev/peps/pep-0008/>.
-
-For consistency with the standard library's ``unittest`` module, method names
-are generally ``camelCase``.
-
-testtools supports Python 2.4 and later, so avoid any 2.5-only features like
-the ``with`` statement.
-
-
-Copyright assignment
---------------------
-
-Part of testtools raison d'etre is to provide Python with improvements to the
-testing code it ships. For that reason we require all contributions (that are
-non-trivial) to meet one of the following rules:
-
- - be inapplicable for inclusion in Python.
- - be able to be included in Python without further contact with the
- contributor.
- - be copyright assigned to Jonathan M. Lange.
-
-Please pick one of these and specify it when contributing code to testtools.
-
-
-Licensing
----------
-
-All code that is not copyright assigned to Jonathan M. Lange (see Copyright
-Assignment above) needs to be licensed under the MIT license that testtools
-uses, so that testtools can ship it.
-
-
-Testing
--------
-
-Please write tests for every feature. This project ought to be a model
-example of well-tested Python code!
-
-Take particular care to make sure the *intent* of each test is clear.
-
-You can run tests with ``make check``, or by running ``./run-tests`` directly.
-
-
-Source layout
--------------
-
-The top-level directory contains the ``testtools/`` package directory, and
-miscellaneous files like README and setup.py.
-
-The ``testtools/`` directory is the Python package itself. It is separated
-into submodules for internal clarity, but all public APIs should be “promoted”
-into the top-level package by importing them in ``testtools/__init__.py``.
-Users of testtools should never import a submodule, they are just
-implementation details.
-
-Tests belong in ``testtools/tests/``.
-
-
-Commiting to trunk
-------------------
-
-Testtools is maintained using bzr, with its trunk at lp:testtools. This gives
-every contributor the ability to commit their work to their own branches.
-However permission must be granted to allow contributors to commit to the trunk
-branch.
-
-Commit access to trunk is obtained by joining the testtools-devs Launchpad
-team. Membership in this team is contingent on obeying the testtools
-contribution policy, including assigning copyright of all the work one creates
-and places in trunk to Jonathan Lange.
-
-
-Code Review
------------
-
-All code must be reviewed before landing on trunk. The process is to create a
-branch in launchpad, and submit it for merging to lp:testtools. It will then
-be reviewed before it can be merged to trunk. It will be reviewed by someone:
-
- * not the author
- * a committer (member of the testtools-devs team)
-
-As a special exception, while the testtools committers team is small and prone
-to blocking, a merge request from a committer that has not been reviewed after
-24 hours may be merged by that committer. When the team is larger this policy
-will be revisited.
-
-Code reviewers should look for the quality of what is being submitted,
-including conformance with this HACKING file.
-
-Changes which all users should be made aware of should be documented in NEWS.
-
-
-NEWS management
----------------
-
-The file NEWS is structured as a sorted list of releases. Each release can have
-a free form description and more or more sections with bullet point items.
-Sections in use today are 'Improvements' and 'Changes'. To ease merging between
-branches, the bullet points are kept alphabetically sorted. The release NEXT is
-permanently present at the top of the list.
-
-
-Release tasks
--------------
-
- 1. Choose a version number, say X.Y.Z
- 1. Branch from trunk to testtools-X.Y.Z
- 1. In testtools-X.Y.Z, ensure __init__ has version X.Y.Z.
- 1. Replace NEXT in NEWS with the version number X.Y.Z, adjusting the reST.
- 1. Possibly write a blurb into NEWS.
- 1. Replace any additional references to NEXT with the version being
- released. (should be none).
- 1. Commit the changes.
- 1. Tag the release, bzr tag testtools-X.Y.Z
- 1. Create a source distribution and upload to pypi ('make release').
- 1. Make sure all "Fix committed" bugs are in the 'next' milestone on
- Launchpad
- 1. Rename the 'next' milestone on Launchpad to 'X.Y.Z'
- 1. Create a release on the newly-renamed 'X.Y.Z' milestone
- 1. Upload the tarball and asc file to Launchpad
- 1. Merge the release branch testtools-X.Y.Z into trunk. Before the commit,
- add a NEXT heading to the top of NEWS and bump the version in __init__.py.
- Push trunk to Launchpad
- 1. If a new series has been created (e.g. 0.10.0), make the series on Launchpad.
- 1. Make a new milestone for the *next release*.
- 1. During release we rename NEXT to $version.
- 1. We call new milestones NEXT.