1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
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. The officially supported _black_ version is the one
in Debian/stable.
* 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.
|
