From 99266ec3ce5309f506d5b62a9a9756818f5b2e78 Mon Sep 17 00:00:00 2001 From: Emil Velikov Date: Sat, 11 Feb 2017 12:08:34 +0000 Subject: [PATCH] docs/submittingpatches: assorted grammar fixes MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Cc: Ben Crocker Suggested-by: Ben Crocker Signed-off-by: Emil Velikov Reviewed-by: Nicolai Hähnle --- docs/submittingpatches.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index d38ccad..f8380b0 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -72,7 +72,7 @@ if needed. For example: platform.
  • A "Signed-off-by:" line is not required, but not discouraged either. -
  • If a patch address a bugzilla issue, that should be noted in the +
  • If a patch addresses a bugzilla issue, that should be noted in the patch comment. For example:
        Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
    @@ -205,7 +205,7 @@ as the issues are resolved first.
     

    Nominating a commit for a stable branch

    -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.

      @@ -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.

      Note: by removing the tag [as the commit is pushed] the patch is @@ -283,7 +283,7 @@ be rejected:

      • 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.
      • Patch is too large, (say, larger than 100 lines)
      • @@ -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. + determined not to have effects on other hardware.
      • Patch is a performance optimization. As a rule, performance patches are not candidates for the stable branch. The only exception might be a case -- 2.7.4