alioth/nixpkgs
3
0
Fork 0
forked from mirrors/nixpkgs
Code Releases Activity

doc/reviewing-contributions: pull-requests -> pull requests

Browse source 
This makes things more consistent. It’s also how GitHub refers to pull
requests.
This commit is contained in:
Matthew Bauer 2018-11-19 12:51:28 -06:00
parent 9d3108c3ae
commit 5e9f452385
2 changed files with 29 additions and 29 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -20,7 +20,7 @@ release and `nixos-unstable` for the latest successful build of master:
% git rebase channels/nixos-18.09
```
For pull-requests, please rebase onto nixpkgs `master`.
For pull requests, please rebase onto nixpkgs `master`.
[NixOS](https://nixos.org/nixos/) Linux distribution source code is located inside
`nixos/` folder.

56
doc/reviewing-contributions.xml
View file

@ -18,35 +18,35 @@
</warning>
<para>
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
pull requests. Reviewing and approving these is an important task and a way
to contribute to the project.
</para>
<para>
The high change rate of Nixpkgs makes any pull-request that remains open for
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
or the merger. Reviewing pull requests in a timely manner and being responsive
to the comments is the key to avoid this issue. GitHub provides sort filters
that can be used to see the <link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most
recently</link> and the <link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least
recently</link> updated pull-requests. We highly encourage looking at
recently</link> updated pull requests. We highly encourage looking at
<link xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone">
this list of ready to merge, unreviewed pull-requests</link>.
this list of ready to merge, unreviewed pull requests</link>.
</para>
<para>
When reviewing a pull-request, please always be nice and polite.
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 member and their work.
</para>
<para>
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
pull requests or any comments. The thumb-down reaction should be used with
care and if possible accompanied with some explanation so the submitter has
directions to improve their contribution.
</para>
<para>
Pull-request 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.
</para>
<para>
@ -58,8 +58,8 @@
<title>Package updates</title>
<para>
A package update is the most trivial and common type of pull-request. These
pull-requests mainly consist of updating the version part of the package
A package update is the most trivial and common type of pull request. These
pull requests mainly consist of updating the version part of the package
name and the source hash.
</para>
@ -75,7 +75,7 @@
<itemizedlist>
<listitem>
<para>
Add labels to the pull-request. (Requires commit rights)
Add labels to the pull request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
@ -142,8 +142,8 @@
<itemizedlist>
<listitem>
<para>
Pull-requests are often targeted to the master or staging branch, and
building the pull-request locally when it is submitted can trigger many
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.
</para>
<para>
@ -172,14 +172,14 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
</callout>
<callout arearefs='reviewing-rebase-3'>
<para>
Fetching the pull-request changes, <varname>PRNUMBER</varname> is the
number at the end of the pull-request title and
<varname>BASEBRANCH</varname> the base branch of the pull-request.
Fetching the pull request changes, <varname>PRNUMBER</varname> is the
number at the end of the pull request title and
<varname>BASEBRANCH</varname> the base branch of the pull request.
</para>
</callout>
<callout arearefs='reviewing-rebase-4'>
<para>
Rebasing the pull-request changes to the nixos-unstable branch.
Rebasing the pull request changes to the nixos-unstable branch.
</para>
</callout>
</calloutlist>
@ -188,10 +188,10 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
<listitem>
<para>
The <link xlink:href="https://github.com/madjar/nox">nox</link> tool can
be used to review a pull-request content in a single command. It doesn't
be used to review a pull request content in a single command. It doesn't
rebase on a channel branch so it might trigger multiple source builds.
<varname>PRNUMBER</varname> should be replaced by the number at the end
of the pull-request title.
of the pull request title.
</para>
<screen>
$ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
@ -228,7 +228,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
<title>New packages</title>
<para>
New packages are a common type of pull-requests. These pull-requests
New packages are a common type of pull requests. These pull requests
consists in adding a new nix-expression for a package.
</para>
@ -239,7 +239,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
<itemizedlist>
<listitem>
<para>
Add labels to the pull-request. (Requires commit rights)
Add labels to the pull request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
@ -359,7 +359,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
<itemizedlist>
<listitem>
<para>
Add labels to the pull-request. (Requires commit rights)
Add labels to the pull request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
@ -472,7 +472,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
<itemizedlist>
<listitem>
<para>
Add labels to the pull-request. (Requires commit rights)
Add labels to the pull request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
@ -574,21 +574,21 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
like to be a long-term reviewer for related submissions, please contact the
current reviewers for that topic. They will give you information about the
reviewing process. The main reviewers for a topic can be hard to find as
there is no list, but checking past pull-requests to see who reviewed or
there is no list, but checking past pull requests to see who reviewed or
git-blaming the code to see who committed to that topic can give some hints.
</para>
<para>
Container system, boot system and library changes are some examples of the
pull-requests fitting this category.
pull requests fitting this category.
</para>
</section>
<section xml:id="reviewing-contributions--merging-pull-requests">
<title>Merging pull-requests</title>
<section xml:id="reviewing-contributions--merging-pull requests">
<title>Merging pull requests</title>
<para>
It is possible for community members that have enough knowledge and
experience on a special topic to contribute by merging pull-requests.
experience on a special topic to contribute by merging pull requests.
</para>
<para>