Rules for Pull Requests

Descriptive titles. Pull requests must have a title that gives the package name the PR is for, and a short description about the PR.
Detailed description. The body of the PR must contain a detailed description of what changes are being introduced, and most importantly, why this PR should be merged.
One package per request. PRs must be for a single package only. A PR addressing multiple packages without merit risks having a delayed merge or being closed.
Squash commits. Your commits must be meaningful. If you make incremental changes or fixes, they must be squashed before the pull request will be merged.
Check that your changes build. Your submission must build using the clean chroot method on all supported architectures that the package is to be built for. No exceptions.
Work within one PR. Do not close a PR and open another with new changes. Amend your commit and force push to your branch to update the changes in the pull request.
Ensure your PR addresses three of the most common problems:
- Correctly update the pkgver or pkgrel of the package (see below).
- Update the checksums if external files have been added or modified.
- Is the package only for specific architectures? Set the buildarch variable (see the README)

Pull requests that fail to meet these requirements may be summarily closed without response.

Submitting new packages

If the pull request is for a new package, review the README to ensure the package is going into the correct repository and meets all the stated requirements.

If you changed the PKGBUILD or related files, detail your changes in the comment header at the top. Review the packages in this repository for examples of what this looks like.
Increment the pkgrel variable by a decimal number if the version of the package is already in the package repositories. This is to prevent interference tracking against upstream versions. For example:
- If pkgrel=1, change to pkgrel=1.1
- If pkgrel=1.1, change to pkgrel=1.2
At no time should an upstream package tracked here exceed the version upstream.
If the package is only supposed to be built for specific architectures, ensure the buildarch variable is set correctly (see the README)

If the change increases the version of the package, ensure pkgver is updated and pkgrel is reset to 1.
Otherwise, increment pkgrel by 1.
If the package is only supposed to be built for specific architectures, ensure the buildarch variable is set correctly (see the README)