X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=docs%2Fsubmittingpatches.html;h=ba09aa4ad7329327e7609b27dd4c756bedf86410;hb=93e213f91f64189ff5fe65844a9fe5b8c48366c2;hp=69835af6ebb223056124fef3a7a25714b058528c;hpb=f9cdfa33c2e01324deba2bf4a5687e7231243d59;p=mesa.git

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 69835af6ebb..ba09aa4ad73 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -78,6 +78,11 @@ patch comment.  For example:
 <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>
@@ -115,7 +120,7 @@ them in the CC list.
 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%)
@@ -146,6 +151,18 @@ Whenever possible and applicable, test the patch with
 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>
 
@@ -174,6 +191,16 @@ When submitting follow-up patches you should also login to
 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>
@@ -219,6 +246,10 @@ release.
 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>
@@ -233,17 +264,11 @@ Here are some examples of such a note:
 </p>
 <ul>
   <li>CC: &lt;mesa-stable@lists.freedesktop.org&gt;</li>
-  <li>CC: "9.2 10.0" &lt;mesa-stable@lists.freedesktop.org&gt;</li>
-  <li>CC: "10.0" &lt;mesa-stable@lists.freedesktop.org&gt;</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
@@ -257,6 +282,10 @@ Note: by removing the tag [as the commit is pushed] the patch is
 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