<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
- <title>Submitting patches</title>
+ <title>Submitting Patches</title>
<link rel="stylesheet" type="text/css" href="mesa.css">
</head>
<body>
<div class="header">
- <h1>The Mesa 3D Graphics Library</h1>
+ The Mesa 3D Graphics Library
</div>
<iframe src="contents.html"></iframe>
<div class="content">
-<h1>Submitting patches</h1>
+<h1>Submitting Patches</h1>
<ul>
if needed. For example:
<pre>
i965: Remove end-of-thread SEND alignment code.
-
+
This was present in Eric's initial implementation of the compaction code
for Sandybridge (commit 077d01b6). There is no documentation saying this
is necessary, and removing it causes no regressions in piglit on any
platform.
</pre>
<li>A "Signed-off-by:" line is not required, but not discouraged either.
-<li>If a patch addresses a bugzilla issue, that should be noted in the
-patch comment. For example:
+<li>If a patch addresses an issue in gitlab, use the Closes: tag
+For example:
<pre>
- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
+ Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
</pre>
+<p>Prefer the full url to just <pre>Closes: #1</pre>, since the url makes it
+easier to get to the bug page from <pre>git log</pre></p>
+<b>Do not use the Fixes: tag for this!</b> Mesa already uses Fixes for something else.
+
<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>You can produce those fixes lines by running
+<pre>git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"</pre>
+once and then using <pre>git fixes <sha1></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>
st/mesa: add ARB_texture_stencil8 support (v4)
-
+
if we support stencil texturing, enable texture_stencil8
there is no requirement to support native S8 for this,
the texture can be converted to x24s8 fine.
-
+
v2: fold fixes from Marek in:
a) put S8 last in the list
b) fix renderable to always test for d/s renderable
<li>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.
-<br>
+<p>
Please use common sense and do <strong>not</strong> blindly add everyone.
-<br>
+</p>
<pre>
$ scripts/get_reviewer.pl --help # to get the help screen
$ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
<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>
<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>
<p>
-replacing <code>"make check"</code> with whatever other test you want to
+replacing <code>"meson test"</code> with whatever other test you want to
run.
</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/>
+email is confidential" and "distribution is strictly prohibited".
+</p>
+<p>
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
</p>
<p>
Add labels to your MR to help reviewers find it. For example:
- <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>
+<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
</p>
<p>
Some other notes:
- <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
- </ul>
</p>
+<ul>
+ <li>Make changes and update your branch based on feedback
+ <li>After an update, for the feedback you handled, close the
+ feedback discussion with the "Resolve Discussion" button. This way
+ the reviewers know which feedback got handled and which didn't.
+ <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>
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
<p>
Here are some examples of such a note:
</p>
-<ul>
- <li>CC: <mesa-stable@lists.freedesktop.org></li>
-</ul>
+<pre>
+CC: <mesa-stable@lists.freedesktop.org>
+</pre>
Simply adding the CC to the mesa-stable list address is adequate to nominate
the commit for all the active stable branches. If the commit is not applicable
<p>
Note: by removing the tag [as the commit is pushed] the patch is
<strong>explicitly</strong> rejected from inclusion in the stable branch(es).
-<br>
Thus, drop the line <strong>only</strong> if you want to cancel the nomination.
</p>
yourself warned.
<h2 id="backports">Sending backports for the stable branch</h2>
+<p>
By default merge conflicts are resolved by the stable-release manager. In which
case he/she should provide a comment about the changes required, alongside the
<code>Conflicts</code> section. Summary of which will be provided in the
<a href="releasing.html#prerelease">pre-release</a> announcement.
-<br>
+</p>
+
+<p>
Developers are interested in sending backports are recommended to use either a
<code>[BACKPORT #branch]</code> subject prefix or provides similar information
within the commit summary.
+</p>
<h2 id="gittips">Git tips</h2>
</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