<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>
<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 <a href="#submit">submitted</a>
-to <a href="#mailing">mesa-dev</a> or with
-a <a href="#merge-request">merge request</a>
+<li>Patches should be <a href="#submit">submitted</a> via a merge request</a>
for <a href="#reviewing">review</a>.
</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>If sending later revision of a patch, add all the tags - ack, r-b,
Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the
patch has already been reviewed.
-<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>
-Please use common sense and do <strong>not</strong> blindly add everyone.
-<br>
-<pre>
- $ 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%)
-</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>
<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>
-
<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 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
-<a href="https://git-scm.com/docs/git-send-email">git send-email</a>
-rather than attaching patches to emails. Sending patches as
-attachments prevents people from being able to provide in-line review
-comments.
+Patches are submitted to the Mesa project via a
+<a href="https://gitlab.freedesktop.org/mesa/mesa">GitLab</a> Merge Request.
</p>
-<p>
-When submitting follow-up patches you can use --in-reply-to to make v2, v3,
-etc patches show up as replies to the originals. This usually works well
-when you're sending out updates to individual patches (as opposed to
-re-sending the whole series). Using --in-reply-to makes
-it harder for reviewers to accidentally review old patches.
-</p>
-
-<p>
-When submitting follow-up patches you should also login to
-<a href="https://patchwork.freedesktop.org">patchwork</a> and change the
-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:
- <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.
- <pre>Allow commits from members who can merge to the target branch</pre>
</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
- <li>Please send MRs from a personal fork rather than from the main
- Mesa repository, as it clutters it unnecessarily.
- </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>
<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.
+ To participate in code review, you can monitor the GitLab Mesa
+ <a href="https://gitlab.freedesktop.org/mesa/mesa/merge_requests">Merge
+ Requests</a> page, and/or register for notifications in your gitlab
+ settings.
</p>
<p>
-When you've reviewed a patch on the mailing list, please be unambiguous
-about your review. That is, state either
+When you've reviewed a patch, please be unambiguous about your review.
+ That is, state either
</p>
<pre>
Reviewed-by: Joe Hacker <jhacker@foo.com>
<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>
git send-email --subject-prefix="PATCH v4" HEAD~8
git send-email -v4 @~8 # shorter version, inherited from git format-patch
</pre>
-<li> Configure git to use the get_reviewer.pl script interactively. Thus you
-can avoid adding the world to the CC list.
-<pre>
- git config sendemail.cccmd "./scripts/get_reviewer.pl -i"
-</pre>
</ul>
projects / mesa.git / blobdiff