X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=docs%2Fsubmittingpatches.html;h=0581391b2958253b8f4d74d1112650becd6c185f;hb=8d5994098f62c509094127aad99c6abff9cb53b1;hp=39b615bc9af392738b1c43be891e335c33e35c0f;hpb=07384468afdbf6eb2ce43072452a6a87c261b56a;p=mesa.git diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index 39b615bc9af..0581391b295 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -25,6 +25,8 @@
  • Reviewing Patches
  • Nominating a commit for a stable branch
  • Criteria for accepting patches to the stable branch +
  • Sending backports for the stable branch +
  • Git tips

    Basic guidelines

    @@ -40,7 +42,7 @@ components. git bisect.)
  • Patches should be properly formatted.
  • Patches should be sufficiently tested before submitting. -
  • Patches should be submitted to submitted to mesa-dev +
  • Patches should be submitted to mesa-dev for review using git send-email. @@ -71,11 +73,16 @@ 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
    +
  • If a patch addresses a issue introduced with earlier commit, that should be +noted in the patch comment. For example: +
    +   Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
+
  • If there have been several revisions to a patch during the review process, they should be noted such as in this example: 
    @@ -103,6 +110,22 @@ that should be documented with:
     Reviewed-by: Joe Hacker <jhacker@foo.com>
     Acked-by: Joe Hacker <jhacker@foo.com>
    +
  • If sending later revision of a patch, add all the tags - ack, r-b, +Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the +patch has already been reviewed. +
  • In order for your patch to reach the prospective reviewer easier/faster, +use the script scripts/get_reviewer.pl to get a list of individuals and include +them in the CC list. +
    +Please use common sense and do not blindly add everyone. +
    +
    +    $ scripts/get_reviewer.pl --help # to get the help screen
+    $ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
+    Rob Herring  (reviewer:ANDROID EGL SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%)
+    Tomasz Figa  (reviewer:ANDROID EGL SUPPORT,authored:12/41=29%,added_lines:308/700=44%,removed_lines:115/283=41%)
+    Emil Velikov  (authored:13/41=32%,removed_lines:76/283=27%)
+
    @@ -123,18 +146,30 @@ to update the tests themselves.

    Whenever possible and applicable, test the patch with -Piglit and/or +Piglit and/or dEQP to check for regressions.

    +

    +As mentioned at the begining, patches should be bisectable. +A good way to test this is to make use of the `git rebase` command, +to run your tests on each commit. Assuming your branch is based off +origin/master, you can run: +

    +$ git rebase --interactive --exec "make check" origin/master
+
    +replacing "make check" with whatever other test you want to +run. +

    +

    Mailing Patches

    Patches should be sent to the mesa-dev mailing list for review: -mesa-dev@lists.freedesktop.org. +mesa-dev@lists.freedesktop.org. When submitting a patch make sure to use git send-email rather than attaching patches to emails. Sending patches as @@ -156,11 +191,22 @@ When submitting follow-up patches you should also login to state of your old patches to Superseded.

    +

    +Some companies' mail server automatically append a legal disclaimer, +usually containing something along the lines of "The information in this +email is confidential" and "distribution is strictly prohibited".
    +These legal notices prevent us from being able to accept your patch, +rendering the whole process pointless. Please make sure these are +disabled before sending your patches. (Note that you may need to contact +your email administrator for this.) +

    +

    Reviewing Patches

    When you've reviewed a patch on the mailing list, please be unambiguous about your review. That is, state either +

         Reviewed-by: Joe Hacker <jhacker@foo.com>
    @@ -168,14 +214,17 @@ or 
         Acked-by: Joe Hacker <jhacker@foo.com>
    +

    Rather than saying just "LGTM" or "Seems OK".

    If small changes are suggested, it's OK to say something like: +

        With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
    +

    which tells the patch author that the patch can be committed, as long as the issues are resolved first.

    @@ -184,7 +233,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.