Reviewing contributions
- The following section is a draft and reviewing policy is still being
- discussed.
+ The following section is a draft, and the policy for reviewing is still being
+ discussed in issues such as #11166
+ and #20836
+ .
- The nixpkgs projects receives a fairly high number of contributions via
+ The nixpkgs project receives a fairly high number of contributions via
GitHub pull-requests. Reviewing and approving these is an important task and
a way to contribute to the project.
- The high change rate of nixpkgs make any pull request that is open for long
- enough subject to conflicts that will require extra work from the submitter
+ The high change rate of nixpkgs makes any pull request that remains open for
+ too long subject to conflicts that will require extra work from the submitter
or the merger. Reviewing pull requests in a timely manner and being
responsive to the comments is the key to avoid these. GitHub provides sort
filters that can be used to see the
@@ -33,34 +37,34 @@
When reviewing a pull request, please always be nice and polite.
Controversial changes can lead to controversial opinions, but it is important
- to respect every community members and their work.
+ to respect every community member and their work.
- GitHub provides reactions, they are a simple and quick way to provide
+ GitHub provides reactions as a simple and quick way to provide
feedback to pull-requests or any comments. The thumb-down reaction should be
- used with care and if possible accompanied with some explanations so the
- submitter has directions to improve his contribution.
+ used with care and if possible accompanied with some explanation so the
+ submitter has directions to improve their contribution.
- Pull-requests reviews should include a list of what has been reviewed in a
+ Pull-request reviews should include a list of what has been reviewed in a
comment, so other reviewers and mergers can know the state of the review.
All the review template samples provided in this section are generic and
meant as examples. Their usage is optional and the reviewer is free to adapt
- them to his liking.
+ them to their liking.
Package updates
A package update is the most trivial and common type of pull-request. These
- pull-requests mainly consist in updating the version part of the package
+ pull-requests mainly consist of updating the version part of the package
name and the source hash.
- It can happen that non trivial updates include patches or more complex
+ It can happen that non-trivial updates include patches or more complex
changes.
@@ -84,12 +88,12 @@
- Ensure that the package versioning is fitting the guidelines.
+ Ensure that the package versioning fits the guidelines.
- Ensure that the commit text is fitting the guidelines.
+ Ensure that the commit text fits the guidelines.
@@ -99,7 +103,7 @@
- mention-bot usually notify GitHub users based on the submitted changes,
+ mention-bot usually notifies GitHub users based on the submitted changes,
but it can happen that it misses some of the package maintainers.
@@ -107,13 +111,13 @@
- Ensure that the meta field contains correct information.
+ Ensure that the meta field information is correct.
- License can change with version updates, so it should be checked to be
- fitting upstream license.
+ License can change with version updates, so it should be checked to match
+ the upstream license.
@@ -137,9 +141,9 @@
- Pull-requests are often targeted to the master or staging branch so
- building the pull-request locally as it is submitted can trigger a large
- amount of source builds.
+ 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