Contributing¶
Coding Standards¶
Follow PEP8. All code is currently PEP8 compliant and it should stay this way.
Changes that fix semantic issues will be generally be happily received, but please keep such changes separate from functional changes.
pep8 targets are provided via tox. Refer to the Testing section below for more information on usage of this tool.
Testing¶
Patchwork includes a tox script to automate testing. This requires a functional database and some Python requirements like tox. Refer to Installation for information on how to configure these.
You may also need to install tox. If so, do this now:
$ sudo pip install tox
Tip
If you’re using Docker or Vagrant-based installs, you may not need to install tox locally. Instead, it will already be installed inside the container/VM. For Docker, you can run tox like so:
$ docker-compose run web tox [ARGS...]
For Vagrant, SSH into the container and run tox as below.
Assuming these requirements are met, actually testing Patchwork is quite easy to do. To start, you can show the default targets like so:
$ tox --list
You’ll see that this includes a number of targets to run unit tests against the
different versions of Django supported, along with some other targets related
to code coverage and code quality. To run one of these, use the -e
parameter:
$ tox -e py27-django18
In the case of the unit tests targets, you can also run specific tests by passing the fully qualified test name as an additional argument to this command:
$ tox -e py27-django18 patchwork.tests.SubjectCleanUpTest
Because Patchwork support multiple versions of Django, it’s very important that you test against all supported versions. When run without argument, tox will do this:
$ tox
Release Notes¶
Patchwork uses reno for release note management. To use reno, you must first install it:
$ sudo pip install tox
Once installed, a new release note can be created using the reno new
command:
$ reno new <slugified-summary-of-change>
Modify the created file, removing any irrelevant sections, and include the modified file in your change.
Submitting Changes¶
All patches should be sent to the mailing list. When doing so, please abide by the QEMU guidelines on contributing or submitting patches. This covers both the initial submission and any follow up to the patches. In particular, ensure:
- All tests pass
- Documentation has been updated with new requirements, new script names etc.
- A release note is included