git bisect.)
git send-email.
+
$ 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%)
+ Rob Herring <robh@kernel.org> (reviewer:ANDROID EGL SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%)
+ Tomasz Figa <tfiga@chromium.org> (reviewer:ANDROID EGL SUPPORT,authored:12/41=29%,added_lines:308/700=44%,removed_lines:115/283=41%)
+ Emil Velikov <emil.l.velikov@gmail.com> (authored:13/41=32%,removed_lines:76/283=27%)
@@ -139,7 +141,7 @@ do whatever testing is prudent.
You should always run the Mesa test suite before submitting patches. -The test suite can be run using the 'make check' command. All tests +The test suite can be run using the 'meson test' command. All tests must pass before patches will be accepted, this may mean you have to update the tests themselves.
@@ -151,11 +153,34 @@ Whenever possible and applicable, test the patch with 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 "meson test -C build/" origin/master ++
+replacing "meson test" with whatever other test you want to
+run.
+
-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. +
+ ++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 @@ -189,8 +214,70 @@ disabled before sending your patches. (Note that you may need to contact your email administrator for this.)
++ 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: +
++ Tick the following when creating the MR. It allows developers to + rebase your work on top of master. +
+Allow commits from members who can merge to the target branch+
+ 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: +
++ 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 @@ -217,6 +304,29 @@ which tells the patch author that the patch can be committed, as long as the issues are resolved first.
++These Reviewed-by, Acked-by, and Tested-by tags should also be amended +into commits in a MR before it is merged. +
+ ++When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR, +enclose the tag in backticks: +
++ `Reviewed-by: Joe Hacker <jhacker@example.com>`+
+This is the markdown format for literal, and will prevent gitlab from hiding +the < and > symbols. +
+ ++Review by non-experts is encouraged. Understanding how someone else +goes about solving a problem is a great way to learn your way around +the project. The submitter is expected to evaluate whether they have +an appropriate amount of review feedback from people who also +understand the code before merging their patches. +
+If you are not the author of the original patch, please Cc: them in your +nomination request. +
++The current patch status can be observed in the staging branch. +
- git rebase -i --exec="make -j4" HEAD~8 + git rebase -i --exec="ninja -C build/" HEAD~8