<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>
<pre>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
</pre>
+<li>If a patch addresses a issue introduced with earlier commit, that should be
+noted in the patch comment. For example:
+<pre>
+ Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
+</pre>
<li>If there have been several revisions to a patch during the review
process, they should be noted such as in this example:
<pre>
Please use common sense and do <strong>not</strong> blindly add everyone.
<br>
<pre>
- $ scripts/get_reviewer.pl --help # to get the the help screen
+ $ scripts/get_reviewer.pl --help # to get the help screen
$ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
- 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%)
+ 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%)
</pre>
</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>
to check for regressions.
</p>
+<p>
+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
+<code>origin/master</code>, you can run:
+</p>
+<pre>
+$ git rebase --interactive --exec "meson test -C build/" origin/master
+</pre>
+<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 should be sent to the mesa-dev mailing list for review:
+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 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
state of your old patches to Superseded.
</p>
+<p>
+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".<br/>
+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.)
+</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>
Note: resending patch identical to one on mesa-dev@ or one that differs only
by the extra mesa-stable@ tag is <strong>not</strong> recommended.
</p>
+<p>
+If you are not the author of the original patch, please Cc: them in your
+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>
</p>
<ul>
<li>CC: <mesa-stable@lists.freedesktop.org></li>
- <li>CC: "9.2 10.0" <mesa-stable@lists.freedesktop.org></li>
- <li>CC: "10.0" <mesa-stable@lists.freedesktop.org></li>
</ul>
Simply adding the CC to the mesa-stable list address is adequate to nominate
-the commit for the most-recently-created stable branch. It is only necessary
-to specify a specific branch name, (such as "9.2 10.0" or "10.0" in the
-examples above), if you want to nominate the commit for an older stable
-branch. And, as in these examples, you can nominate the commit for the older
-branch in addition to the more recent branch, or nominate the commit
-exclusively for the older branch.
+the commit for all the active stable branches. If the commit is not applicable
+for said branch the stable-release manager will reply stating so.
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
Thus, drop the line <strong>only</strong> if you want to cancel the nomination.
</p>
+Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting"
+section, it nominates a commit for all active stable branches that include the
+commit that is referred to.
+
<h2 id="criteria">Criteria for accepting patches to the stable branch</h2>
Mesa has a designated release manager for each stable branch, and the release
</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