mirror of
https://gitlab.com/fdroid/fdroidserver.git
synced 2024-11-04 14:30:11 +01:00
66 lines
3.5 KiB
Markdown
66 lines
3.5 KiB
Markdown
There are many ways to contribute, you can find out all the ways on our
|
|
[Contribute](https://f-droid.org/contribute/) page. Find out how to get
|
|
involved, including as a translator, data analyst, tester, helping others, and
|
|
much more!
|
|
|
|
## Contributing Code
|
|
|
|
We want more contributors and want different points of view represented. Some
|
|
parts of the code make contributing quick and easy. Other parts make it
|
|
difficult and slow, so we ask that contributors have patience.
|
|
|
|
To submit a patch, please open a merge request on GitLab. If you are thinking of
|
|
making a large contribution, open an issue or merge request before starting
|
|
work, to get comments from the community. Someone may be already working on the
|
|
same thing, or there may be reasons why that feature isn't implemented. Once
|
|
there is agreement, then the work might need to proceed asynchronously with the
|
|
core team towards the solution.
|
|
|
|
To make it easier to review and accept your merge request, please follow these
|
|
guidelines:
|
|
|
|
* When at all possible, include tests. These can either be added to an existing
|
|
test, or completely new. Practicing test-driven development will make it
|
|
easiest to get merged. That usually means starting your work by writing tests.
|
|
|
|
* See [help-wanted](https://gitlab.com/fdroid/fdroidserver/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=help-wanted)
|
|
tags for things that maintainers have marked as things they want to see
|
|
merged.
|
|
|
|
* The amount of technical debt varies widely in this code base. There are some
|
|
parts where the code is nicely isolated with good test coverage. There are
|
|
other parts that are tangled and complicated, full of technical debt, and
|
|
difficult to test.
|
|
|
|
* The general approach is to treat the tangled and complicated parts as an
|
|
external API (albeit a bad one). That means it needs to stay unchanged as much
|
|
as possible. Changes to those parts of the code will trigger a migration,
|
|
which can require a lot of time and coordination. When there is time for large
|
|
development efforts, we refactor the code to get rid of those areas of
|
|
technical debt.
|
|
|
|
* We use [_black_](https://black.readthedocs.io/) code format, run `black .` to
|
|
format the code. Whenever editing code in any file, the new code should be
|
|
formatted as _black_. Some files are not yet fully in _black_ format (see
|
|
_pyproject.toml_), our goal is to opportunistically convert the code whenever
|
|
possible. As of the time of this writing, forcing the code format on all files
|
|
would be too disruptive.
|
|
|
|
* Many of the tests run very fast and can be run interactively in isolation.
|
|
Some of the essential test cases run slowly because they do things like
|
|
signing files and generating signing keys.
|
|
|
|
* Some parts of the code are difficult to test, and currently require a
|
|
relatively complete production setup in order to effectively test them. That
|
|
is mostly the code around building packages, managing the disposable VM, and
|
|
scheduling build jobs to run.
|
|
|
|
* For user visible changes (API changes, behaviour changes, etc.), consider
|
|
adding a note in _CHANGELOG.md_. This could be a summarizing description of
|
|
the change, and could explain the grander details. Have a look through
|
|
existing entries for inspiration. Please note that this is NOT simply a copy
|
|
of git-log one-liners. Also note that security fixes get an entry in
|
|
_CHANGELOG.md_. This file helps users get more in-depth information of what
|
|
comes with a specific release without having to sift through the higher noise
|
|
ratio in git-log.
|