docs/submittingpatches: assorted grammar fixes
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>
This commit is contained in:

committed by
Emil Velikov

parent
e280a6bc8a
commit
99266ec3ce
@@ -72,7 +72,7 @@ if needed. For example:
|
|||||||
platform.
|
platform.
|
||||||
</pre>
|
</pre>
|
||||||
<li>A "Signed-off-by:" line is not required, but not discouraged either.
|
<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:
|
patch comment. For example:
|
||||||
<pre>
|
<pre>
|
||||||
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
|
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>
|
<h2 id="nominations">Nominating a commit for a stable branch</h2>
|
||||||
|
|
||||||
<p>
|
<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.
|
release.
|
||||||
</p>
|
</p>
|
||||||
<ul>
|
<ul>
|
||||||
@@ -247,7 +247,7 @@ exclusively for the older branch.
|
|||||||
This "CC" syntax for patch nomination will cause patches to automatically be
|
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
|
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
|
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>
|
<p>
|
||||||
Note: by removing the tag [as the commit is pushed] the patch is
|
Note: by removing the tag [as the commit is pushed] the patch is
|
||||||
@@ -283,7 +283,7 @@ be rejected:
|
|||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>Patch introduces a regression. Any reported build breakage or other
|
<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>
|
changes from PASS to FAIL), is justification for rejecting a patch.</li>
|
||||||
|
|
||||||
<li>Patch is too large, (say, larger than 100 lines)</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
|
Note: As an exception to this rule, the stable-release manager may accept
|
||||||
hardware-enabling "features". For example, backports of new code to support
|
hardware-enabling "features". For example, backports of new code to support
|
||||||
a newly-developed hardware product can be accepted if they can be reasonably
|
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
|
<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
|
not candidates for the stable branch. The only exception might be a case
|
||||||
|
Reference in New Issue
Block a user