summary refs log tree commit diff
diff options
context:
space:
mode:
authorMatthew Bauer <mjbauer95@gmail.com>2018-11-19 12:51:28 -0600
committerMatthew Bauer <mjbauer95@gmail.com>2018-11-19 13:03:23 -0600
commit5e9f452385e46058abde6011e902adf070ba86c3 (patch)
treee71a70361bc2bf7ddd4e63ed4914902e32150fa9
parent9d3108c3aee8214d26218e8c2be3b4d497246fbe (diff)
downloadnixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.tar
nixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.tar.gz
nixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.tar.bz2
nixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.tar.lz
nixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.tar.xz
nixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.tar.zst
nixpkgs-5e9f452385e46058abde6011e902adf070ba86c3.zip
doc/reviewing-contributions: pull-requests -> pull requests
This makes things more consistent. It’s also how GitHub refers to pull
requests.
-rw-r--r--README.md2
-rw-r--r--doc/reviewing-contributions.xml56
2 files changed, 29 insertions, 29 deletions
diff --git a/README.md b/README.md
index 278ef66cf7e..29c023e4dcd 100644
--- a/README.md
+++ b/README.md
@@ -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.
diff --git a/doc/reviewing-contributions.xml b/doc/reviewing-contributions.xml
index 79ebc400d36..0bf3dc9e9f8 100644
--- a/doc/reviewing-contributions.xml
+++ b/doc/reviewing-contributions.xml
@@ -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>