These are the contribution guidelines for repod.
Development of repod takes place on Arch Linux’ Gitlab: https://gitlab.archlinux.org/archlinux/repod.
Please read our distribution-wide Code of Conduct before contributing, to understand what actions will and will not be tolerated.
All code contributions fall under the terms of the GPL-3.0-or-later.
All documentation contributions fall under the terms of the GFDL-1.3-or-later.
All past and present authors of repod are listed in Authors.
Discussion around repod takes place on the arch-projects mailing list and in #archlinux-projects on Libera Chat.
The project is written in typed Python. Please refer to the issue tracker for open tickets and ongoing development.
Tox and pdm need to be installed to be able to test the project’s code and to generate its user facing documentation.
The code base is type checked, linted and formatted using standardized tooling.
Please make sure to run
tox before providing a merge request.
For all notable changes to the code base make sure to add a Changelog entry in the [Unreleased] section.
The changelog style follows the keep a changelog methodology.
Valid subsection topics are:
Added for new features.
Changed for changes in existing functionality.
Deprecated for soon-to-be removed features.
Removed for now removed features.
Fixed for any bug fixes.
Security in case of vulnerabilities.
Integration for text editors
An editorconfig file is provided in the code repository repository and the text editor in use should be configured to make use of it.
Additional helpful integrations for linting and type checking are:
All code is documented following numpydoc (see the accompanying style guide for further info).
Test cases are developed per module in the
tests/ directory using
pytest and should consist of atomic single
Huge test cases asserting various different expectations are discouraged and
should be split into finer grained test cases or covered using parametrized
New code additions are not accepted below 100% test coverage.
The tests are distinguished between coverage tests and integration tests. While the former are meant to target what is commonly referred to as unit tests, the latter are meant to test more complex scenarios, involving actual repository actions, etc.
To execute all coverage tests use
tox -e coverage-linux
tox -e coverage-macos
To run all integration tests use
tox -e integration
Documentation is written in reStructuredText and
assembled using sphinx
To build the documentation use
tox -e docs