<li><a href="#guidelines">Basic guidelines</a>
<li><a href="#formatting">Patch formatting</a>
<li><a href="#testing">Testing Patches</a>
-<li><a href="#mailing">Mailing Patches</a>
+<li><a href="#submit">Submitting Patches</a>
<li><a href="#reviewing">Reviewing Patches</a>
<li><a href="#nominations">Nominating a commit for a stable branch</a>
<li><a href="#criteria">Criteria for accepting patches to the stable branch</a>
perhaps, in very trivial cases.)
<li>Code patches should follow Mesa
<a href="codingstyle.html" target="_parent">coding conventions</a>.
-<li>Whenever possible, patches should only effect individual Mesa/Gallium
+<li>Whenever possible, patches should only affect individual Mesa/Gallium
components.
<li>Patches should never introduce build breaks and should be bisectable (see
<code>git bisect</code>.)
<li>Patches should be properly <a href="#formatting">formatted</a>.
<li>Patches should be sufficiently <a href="#testing">tested</a> before submitting.
-<li>Patches should be submitted to <a href="#mailing">mesa-dev</a>
-for <a href="#reviewing">review</a> using <code>git send-email</code>.
+<li>Patches should be <a href="#submit">submitted</a>
+to <a href="#mailing">mesa-dev</a> or with
+a <a href="#merge-request">merge request</a>
+for <a href="#reviewing">review</a>.
</ul>
<p>
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.
</p>
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
<code>origin/master</code>, you can run:
+</p>
<pre>
-$ git rebase --interactive --exec "make check" origin/master
+$ git rebase --interactive --exec "meson test -C build/" origin/master
</pre>
-replacing <code>"make check"</code> with whatever other test you want to
+<p>
+replacing <code>"meson test"</code> with whatever other test you want to
run.
</p>
-<h2 id="mailing">Mailing Patches</h2>
+<h2 id="submit">Submitting Patches</h2>
+
+<p>
+Patches may be submitted to the Mesa project by
+<a href="#mailing">email</a> or with a
+GitLab <a href="#merge-request">merge request</a>. To prevent
+duplicate code review, only use one method to submit your changes.
+</p>
+
+<h3 id="mailing">Mailing Patches</h3>
<p>
-Patches should be sent to the mesa-dev mailing list for review:
+Patches may be sent to the mesa-dev mailing list for review:
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">
mesa-dev@lists.freedesktop.org</a>.
When submitting a patch make sure to use
your email administrator for this.)
</p>
+<h3 id="merge-request">GitLab Merge Requests</h3>
+
+<p>
+ <a href="https://gitlab.freedesktop.org/mesa/mesa">GitLab</a> Merge
+ Requests (MR) can also be used to submit patches for Mesa.
+</p>
+
+<p>
+ 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.
+</p>
+<p>
+ Add labels to your MR to help reviewers find it. For example:
+</p>
+<ul>
+ <li>Mesa changes affecting all drivers: mesa
+ <li>Hardware vendor specific code: amd, intel, nvidia, ...
+ <li>Driver specific code: anvil, freedreno, i965, iris, radeonsi,
+ radv, vc4, ...
+ <li>Other tag examples: gallium, util
+</ul>
+<p>
+ Tick the following when creating the MR. It allows developers to
+ rebase your work on top of master.
+</p>
+<pre>Allow commits from members who can merge to the target branch</pre>
+<p>
+ If you revise your patches based on code review and push an update
+ to your branch, you should maintain a <strong>clean</strong> 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.
+</p>
+<p>
+ 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.
+</p>
+<p>
+ Some other notes:
+</p>
+<ul>
+ <li>Make changes and update your branch based on feedback
+ <li>Old, stale MR may be closed, but you can reopen it if you
+ still want to pursue the changes
+ <li>You should periodically check to see if your MR needs to be
+ rebased
+ <li>Make sure your MR is closed if your patches get pushed outside
+ of GitLab
+ <li>Please send MRs from a personal fork rather than from the main
+ Mesa repository, as it clutters it unnecessarily.
+</ul>
+
<h2 id="reviewing">Reviewing Patches</h2>
+<p>
+ To participate in code review, you should monitor the
+ <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">
+ mesa-dev</a> email list and the GitLab
+ Mesa <a href="https://gitlab.freedesktop.org/mesa/mesa/merge_requests">Merge
+ Requests</a> page.
+</p>
+
<p>
When you've reviewed a patch on the mailing list, please be unambiguous
about your review. That is, state either
as the issues are resolved first.
</p>
+<p>
+These Reviewed-by, Acked-by, and Tested-by tags should also be amended
+into commits in a MR before it is merged.
+</p>
+
+<p>
+When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR,
+enclose the tag in backticks:
+</p>
+<pre>
+ `Reviewed-by: Joe Hacker <jhacker@example.com>`</pre>
+<p>
+This is the markdown format for literal, and will prevent gitlab from hiding
+the < and > symbols.
+</p>
+
+<p>
+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.
+</p>
<h2 id="nominations">Nominating a commit for a stable branch</h2>
nomination request.
</p>
+<p>
+The current patch status can be observed in the <a href="releasing.html#stagingbranch">staging branch</a>.
+</p>
<h3 id="thetag">The stable tag</h3>
</pre>
<li>Test for build breakage between patches e.g last 8 commits.
<pre>
- git rebase -i --exec="make -j4" HEAD~8
+ git rebase -i --exec="ninja -C build/" HEAD~8
</pre>
<li>Sets the default mailing address for your repo.
<pre>
projects / mesa.git / blobdiff