docs/submittingpatches: assorted grammar fixes
authorEmil Velikov <emil.velikov@collabora.com>
Sat, 11 Feb 2017 12:08:34 +0000 (12:08 +0000)
committerEmil Velikov <emil.l.velikov@gmail.com>
Thu, 16 Feb 2017 15:17:51 +0000 (15:17 +0000)
Cc: Ben Crocker <bcrocker@redhat.com>
Suggested-by: Ben Crocker <bcrocker@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
docs/submittingpatches.html

index d38ccad872fabe220f26530ef3b1432ec0a6c861..f8380b0a54267075dd8f0b15097be5780eb28ed1 100644 (file)
@@ -72,7 +72,7 @@ if needed.  For example:
     platform.
 </pre>
 <li>A "Signed-off-by:" line is not required, but not discouraged either.
-<li>If a patch address a bugzilla issue, that should be noted in the
+<li>If a patch addresses a bugzilla issue, that should be noted in the
 patch comment.  For example:
 <pre>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
@@ -205,7 +205,7 @@ as the issues are resolved first.
 <h2 id="nominations">Nominating a commit for a stable branch</h2>
 
 <p>
-There are three ways to nominate patch for inclusion of the stable branch and
+There are three ways to nominate a patch for inclusion in the stable branch and
 release.
 </p>
 <ul>
@@ -247,7 +247,7 @@ exclusively for the older branch.
 This "CC" syntax for patch nomination will cause patches to automatically be
 copied to the mesa-stable@ mailing list when you use "git send-email" to send
 patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that
-won't have any effect negative effect on the patch nomination.
+won't have any negative effect on the patch nomination.
 
 <p>
 Note: by removing the tag [as the commit is pushed] the patch is
@@ -283,7 +283,7 @@ be rejected:
 
 <ul>
   <li>Patch introduces a regression. Any reported build breakage or other
-  regression caused by a particular patch, (game no longer work, piglit test
+  regression caused by a particular patch, (game no longer works, piglit test
   changes from PASS to FAIL), is justification for rejecting a patch.</li>
 
   <li>Patch is too large, (say, larger than 100 lines)</li>
@@ -322,7 +322,7 @@ be rejected:
   Note: As an exception to this rule, the stable-release manager may accept
   hardware-enabling "features". For example, backports of new code to support
   a newly-developed hardware product can be accepted if they can be reasonably
-  determined to not have effects on other hardware.</li>
+  determined not to have effects on other hardware.</li>
 
   <li>Patch is a performance optimization. As a rule, performance patches are
   not candidates for the stable branch. The only exception might be a case