From 7fe4e0ad5d9a5f0c292ad3ec420423f97842cad2 Mon Sep 17 00:00:00 2001 From: Jordan Justen Date: Tue, 27 Nov 2018 15:39:10 -0800 Subject: [PATCH] docs: Document GitLab merge request process (email alternative) This documents a process for using GitLab Merge Requests as an second way to submit code changes for Mesa. Only one of the two methods is allowed for each patch series. We will *not* require all patches to be emailed. Some code changes may be reviewed and merged without any discussion on the mesa-dev email list. v2: * No longer require email. Allow submitter to choose email or a GitLab merge request. * Various feedback from Brian, Daniel, Dylan, Eric, Erik, Jason, Matt, Michel and Rob. Signed-off-by: Jordan Justen Acked-by: Jason Ekstrand Reviewed-by: Eric Anholt Acked-by: Dylan Baker Reviewed-by: Erik Faye-Lund Reviewed-by: Eric Engestrom Acked-by: Bas Nieuwenhuizen Acked-by: Rob Clark --- docs/submittingpatches.html | 76 ++++++++++++++++++++++++++++++++++--- 1 file changed, 71 insertions(+), 5 deletions(-) diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index 3f97c941aa5..e381a88f95b 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -21,7 +21,7 @@
  • Basic guidelines
  • Patch formatting
  • Testing Patches -
  • Mailing Patches +
  • Submitting Patches
  • Reviewing Patches
  • Nominating a commit for a stable branch
  • Criteria for accepting patches to the stable branch @@ -42,8 +42,10 @@ components. git bisect.)
  • Patches should be properly formatted.
  • Patches should be sufficiently tested before submitting. -
  • Patches should be submitted to mesa-dev -for review using git send-email. +
  • Patches should be submitted +to mesa-dev or with +a merge request +for review. @@ -166,10 +168,19 @@ run.

    -

    Mailing Patches

    +

    Submitting Patches

    -Patches should be sent to the mesa-dev mailing list for review: +Patches may be submitted to the Mesa project by +email or with a +GitLab merge request. To prevent +duplicate code review, only use one method to submit your changes. +

    + +

    Mailing Patches

    + +

    +Patches may be sent to the mesa-dev mailing list for review: mesa-dev@lists.freedesktop.org. When submitting a patch make sure to use @@ -203,8 +214,63 @@ disabled before sending your patches. (Note that you may need to contact your email administrator for this.)

    +

    GitLab Merge Requests

    + +

    + GitLab Merge + Requests (MR) can also be used to submit patches for Mesa. +

    + +

    + If the MR may have interest for most of the Mesa community, you can + send an email to the mesa-dev email list including a link to the MR. + Don't send the patch to mesa-dev, just the MR link. +

    +

    + Add labels to your MR to help reviewers find it. For example: +

      +
    • Mesa changes affecting all drivers: mesa +
    • Hardware vendor specific code: amd, intel, nvidia, ... +
    • Driver specific code: anvil, freedreno, i965, iris, radeonsi, + radv, vc4, ... +
    • Other tag examples: gallium, util +
    +

    +

    + If you revise your patches based on code review and push an update + to your branch, you should maintain a clean history + in your patches. There should not be "fixup" patches in the history. + The series should be buildable and functional after every commit + whenever you push the branch. +

    +

    + It is your responsibility to keep the MR alive and making progress, + as there are no guarantees that a Mesa dev will independently take + interest in it. +

    +

    + Some other notes: +

      +
    • Make changes and update your branch based on feedback +
    • Old, stale MR may be closed, but you can reopen it if you + still want to pursue the changes +
    • You should periodically check to see if your MR needs to be + rebased +
    • Make sure your MR is closed if your patches get pushed outside + of GitLab +
    +

    +

    Reviewing Patches

    +

    + To participate in code review, you should monitor the + + mesa-dev email list and the GitLab + Mesa Merge + Requests page. +

    +

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