aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEmil Velikov <[email protected]>2017-02-11 12:08:34 +0000
committerEmil Velikov <[email protected]>2017-02-16 15:17:51 +0000
commit99266ec3ce5309f506d5b62a9a9756818f5b2e78 (patch)
treefcdcae9027cd9e876d3172a7951bfcf9dd80bb9b
parente280a6bc8a3a204972438758abfd0b554563c171 (diff)
docs/submittingpatches: assorted grammar fixes
Cc: Ben Crocker <[email protected]> Suggested-by: Ben Crocker <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
-rw-r--r--docs/submittingpatches.html10
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index d38ccad872f..f8380b0a542 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -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