Contributor guide¶
Thanks for considering contributing to fedora-messaging, we really appreciate it!
Quickstart¶
Look for an existing issue about the bug or feature you’re interested in. If you can’t find an existing issue, create a new one.
Fork the repository on GitHub.
Fix the bug or add the feature, and then write one or more tests which show the bug is fixed or the feature works.
Add a news fragment with a summary of the change to include in the upcoming release notes.
Submit a pull request and wait for a maintainer to review it.
More detailed guidelines to help ensure your submission goes smoothly are below.
Note
If you do not wish to use GitHub, please send patches to infrastructure@lists.fedoraproject.org.
Python Support¶
fedora-messaging supports Python 3.6 or greater. This is automatically enforced by the continuous integration (CI) suite.
Code Style¶
We follow the PEP8 style guide for Python. This is automatically enforced by the CI suite.
We are using Black <https://github.com/ambv/black> to automatically format the source code. It is also checked in CI. The Black webpage contains instructions to configure your editor to run it on the files you edit.
We use pre-commit to run a set of linters and formatters upon commit.
To setup to hook for your repo clone, install pre-commit and run pre-commit install
.
Tests¶
The test suites can be run using tox by simply
running tox
from the repository root. All code must have test coverage or
be explicitly marked as not covered using the # no-qa
comment. This should
only be done if there is a good reason to not write tests.
Your pull request should contain tests for your new feature or bug fix. If you’re not certain how to write tests, we will be happy to help you.
Release notes¶
To add entries to the release notes, run towncrier create <source.type>
to
create a news fragment file in the news
directory, where type
is one of:
feature
: for new featuresbug
: for bug fixesapi
: for API changesdev
: for development-related changesdocs
: for documentation changesauthor
: for contributor namesother
: for other changes
And where the source
part of the filename is:
42
when the change is described in issue42
PR42
when the change has been implemented in pull request42
, and there is no associated issueCabcdef
when the change has been implemented in changesetabcdef
, and there is no associated issue or pull request.username
for contributors (author
extention). It should be the username part of their commits’ email address.
For example,
towncrier create PR42.feature
The contents of the news fragment must be written in RST format. See the towncrier documentation for more information.
A preview of the release notes can be generated with towncrier --draft
.
Licensing¶
Your commit messages must include a Signed-off-by tag with your name and e-mail address, indicating that you agree to the Developer Certificate of Origin version 1.1:
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Use git commit -s
to add the Signed-off-by tag.
Releasing¶
When cutting a new release, follow these steps:
update the version in
pyproject.toml
add missing authors to the release notes fragments by changing to the
news
directory and running theget-authors.py
script, but check for duplicates and errorsgenerate the changelog by running
poetry run towncrier build
adjust the release notes in
docs/changelog.rst
generate the docs with
tox -e docs
and check them indocs/_build/html
change the
Development Status
classifier inpyproject.toml
if necessarycommit the changes
push the commit to the upstream Github repository (via a PR or not).
change to the stable branch and merge the
develop
branchrun the checks with
tox
one last time to be suretag the commit with
-s
to generate a signed tagpush the commit to the upstream Github repository with
git push
and the new tag withgit push --tags
generate a tarball and push to PyPI with the commands:
python setup.py sdist bdist_wheel
twine upload -s dist/*
create the release on GitHub and copy the release notes in there
deploy and announce