Cyber
/
PKGBUILDs
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update CONTRIBUTING.md

This commit is contained in:
Kevin Mihelich 2015-12-17 20:30:04 -07:00
parent ffc1f45956
commit 965e241b3d
1 changed files with 17 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
CONTRIBUTING.md
View File

@ -1,59 +1,31 @@
## New Issues
This issue tracker is for bugs with packaging, and the PKGBUILDs *only*. Use [the forum](http://archlinuxarm.org/forum) for *all* other issues.
# Rules for Pull Requests
*Before* filing an issue, copy and paste the following template. **This is required to be completely filled out.**
```AsciiDoc
Package:
Architecture:
Device:
What it isn't doing:
What it should be doing:
Steps to reproduce:
```
The issue title must contain the package name and a short description of the problem:
```AsciiDoc
package-name: short description
```
#### You can [click this link](https://github.com/archlinuxarm/PKGBUILDs/issues/new?title=package-name:%20short%20description&body=Package:%20%0AArchitecture:%20%0ADevice:%20%0A%0AWhat%20it%20isn%27t%20doing:%0A%0AWhat%20it%20should%20be%20doing:%0A%0ASteps%20to%20reproduce:%0A) to automatically pre-fill a new issue.
Field | Description
---- | -----
Package | The package name of the package with the problem (eg. linux-armv7)
Architecture | The architecture this package is from (armv5, armv6, armv7, armv8)
Device | The ARM device used where the problem occurred (eg. Wandboard)
What it isn't doing | A **detailed** account of the problem, including all relevant error messages
What it should be doing | A **detailed** description of what correct operation looks like
Steps to reproduce | A **detailed** guide on how to successfully reproduce the problem
---
## Pull Requests
* Pull requests should have a title that gives the package name the PR is for, and a short description about the PR.
* The body of the PR should contain a **detailed** description of what changes are being introduced, and most importantly, *why* this PR should be merged.
* PRs must be for a single package only. A PR addressing multiple packages without merit risks having a delayed merge or being closed.
* **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](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Squashing-Commits) before the pull request will be merged.
* **Check that your changes build.** Your submission must build using the [clean chroot](https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_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](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md))
### New Packages
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](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md) to ensure the package is going into the correct repository and meets all the stated requirements.
### Existing packages
#### Upstream x86 Arch Linux packages
* If you changed the PKGBUILD or related files, detail your changes in the comment header at the top.
* Increment the pkgrel variable by a decimal number. This is to prevent interference tracking against upstream versions. For example:
## Updating existing packages
### Upstream x86 Arch Linux packages
* 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 a specific architecture, ensure the `buildarch` variable is set correctly (see [the README](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md))
* If the package is only supposed to be built for specific architectures, ensure the `buildarch` variable is set correctly (see [the README](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md))
#### Arch Linux ARM specific packages
### Arch Linux ARM specific packages
* 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 a specific architecture, ensure the `buildarch` variable is set correctly (see [the README](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md))
* If the package is only supposed to be built for specific architectures, ensure the `buildarch` variable is set correctly (see [the README](https://github.com/archlinuxarm/PKGBUILDs/blob/master/README.md))