To compile from source, refer to the [in-tree documentation]({{ config.repo_url }}/tree/master/doc), and, specifically, the [installation instructions]({{ config.repo_url }}/blob/master/doc/INSTALL).
Look into the repository for the embedded documentation and `README` files in subdirectories. An archive of the (mostly obsolete, but partly still valuable) documentation from the Trac wiki pages is available here: <{{ extra.organization_url }}/trac-archive/wiki>.
We require an issue (or pull request) and [code review](#code-review) for any code contribution, except for the following, which can be committed directly to the development branch:
All contributors must acknowledge that they own the rights to the code they contribute by signing their commits with `git commit --amend -s` (adding a `Signed-off-by:` line to the commit message). This signifies that they abide by the [Developer Certificate of Origin, Version 1.1](https://developercertificate.org), which is also used by the Linux kernel.
A lot of great (and sometimes not so great) literature has been written about code review over the decades. We do not intend to cover code review in detail here, just highlight the points that are most relevant to our process.
A good place to start learning about code review in general is [Your code sucks, and I hate you](https://jml.io/your-code-sucks-and-i-hate-you/) by Jonathan Lange.
For every release, we create a cleanup branch like `4633_cleanup` to aggregate small code changes, connected to the corresponding release ticket (e.g. [#4633]({{ config.repo_url }}/issues/4633)).
* The cleanup branch should be created as needed and merged back in periodically (currently every few months).
* Delete the cleanup branch after merging it into the main branch and re-create it later with the same name if necessary.
* The cleanup branch should be merged into the main branch no later than a few weeks before the release to allow enough time for the changes to be tested by developers and users.
