diff options
Diffstat (limited to 'pkgs/README.md')
| -rw-r--r-- | pkgs/README.md | 49 |
1 files changed, 35 insertions, 14 deletions
diff --git a/pkgs/README.md b/pkgs/README.md index 642833d968f..31a590e43d8 100644 --- a/pkgs/README.md +++ b/pkgs/README.md @@ -114,6 +114,25 @@ Now that this is out of the way. To add a package to Nixpkgs: 7. Optionally commit the new package and open a pull request [to nixpkgs](https://github.com/NixOS/nixpkgs/pulls), or use [the Patches category](https://discourse.nixos.org/t/about-the-patches-category/477) on Discourse for sending a patch without a GitHub account. +## Commit conventions + +- Make sure you read about the [commit conventions](../CONTRIBUTING.md#commit-conventions) common to Nixpkgs as a whole. + +- Format the commit messages in the following way: + + ``` + (pkg-name): (from -> to | init at version | refactor | etc) + + (Motivation for change. Link to release notes. Additional information.) + ``` + + Examples: + + * nginx: init at 2.0.1 + * firefox: 54.0.1 -> 55.0 + + https://www.mozilla.org/en-US/firefox/55.0/releasenotes/ + ## Category Hierarchy [categories]: #category-hierarchy @@ -696,16 +715,16 @@ It can happen that non-trivial updates include patches or more complex changes. Reviewing process: -- Ensure that the package versioning fits the guidelines. -- Ensure that the commit text fits the guidelines. +- Ensure that the package versioning [fits the guidelines](#versioning). +- Ensure that the commit text [fits the guidelines](../CONTRIBUTING.md#commit-conventions). - Ensure that the package maintainers are notified. - [CODEOWNERS](https://help.github.com/articles/about-codeowners) will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers. -- Ensure that the meta field information is correct. +- Ensure that the meta field information [fits the guidelines](#meta-attributes) and is correct: - License can change with version updates, so it should be checked to match the upstream license. - If the package has no maintainer, a maintainer must be set. This can be the update submitter or a community member that accepts to take maintainership of the package. - Ensure that the code contains no typos. -- Building the package locally. - - pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds. +- Build the package locally. + - Pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds. - It is possible to rebase the changes on nixos-unstable or nixpkgs-unstable for easier review by running the following commands from a nixpkgs clone. ```ShellSession @@ -722,7 +741,7 @@ Reviewing process: ```ShellSession $ nix-shell -p nixpkgs-review --run "nixpkgs-review pr PRNUMBER" ``` -- Running every binary. +- Run every binary. Sample template for a package update review is provided below. @@ -731,7 +750,7 @@ Sample template for a package update review is provided below. - [ ] package name fits guidelines - [ ] package version fits guidelines -- [ ] package build on ARCHITECTURE +- [ ] package builds on ARCHITECTURE - [ ] executables tested on ARCHITECTURE - [ ] all depending packages build - [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed @@ -748,18 +767,20 @@ New packages are a common type of pull requests. These pull requests consists in Review process: -- Ensure that the package versioning fits the guidelines. -- Ensure that the commit name fits the guidelines. -- Ensure that the meta fields contain correct information. +- Ensure that all file paths [fit the guidelines](../CONTRIBUTING.md#file-naming-and-organisation). +- Ensure that the package name and version [fits the guidelines](#package-naming). +- Ensure that the package versioning [fits the guidelines](#versioning). +- Ensure that the commit text [fits the guidelines](../CONTRIBUTING.md#commit-conventions). +- Ensure that the meta fields [fits the guidelines](#meta-attributes) and contain the correct information: - License must match the upstream license. - Platforms should be set (or the package will not get binary substitutes). - Maintainers must be set. This can be the package submitter or a community member that accepts taking up maintainership of the package. - Report detected typos. - Ensure the package source: - - Uses mirror URLs when available. + - Uses `mirror://` URLs when available. - Uses the most appropriate functions (e.g. packages from GitHub should use `fetchFromGitHub`). -- Building the package locally. -- Running every binary. +- Build the package locally. +- Run every binary. Sample template for a new package review is provided below. @@ -769,7 +790,7 @@ Sample template for a new package review is provided below. - [ ] package path fits guidelines - [ ] package name fits guidelines - [ ] package version fits guidelines -- [ ] package build on ARCHITECTURE +- [ ] package builds on ARCHITECTURE - [ ] executables tested on ARCHITECTURE - [ ] `meta.description` is set and fits guidelines - [ ] `meta.license` fits upstream license |