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>
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