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>.)
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>
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:
+<pre>
+$ git rebase --interactive --exec "make check" origin/master
+</pre>
+replacing <code>"make check"</code> with whatever other test you want to
+run.
+</p>
+
<h2 id="mailing">Mailing Patches</h2>
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>
+
<h2 id="reviewing">Reviewing Patches</h2>
<p>
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>
<h3 id="thetag">The stable tag</h3>
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