dri: Reuse dri_message to implement our other message handlers.

[mesa.git] / docs / devinfo.html

diff --git a/docs/devinfo.html b/docs/devinfo.html
index bf7725961ce4333e6b0ed00333f03ecef9f53aea..d4a6dfb590d63998a039db0836b86b7b8c208f70 100644 (file)
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -17,7 +17,7 @@
 <h1>Development Notes</h1>
 
 
-<h2>Adding Extentions</h2>
+<h2>Adding Extensions</h2>
 
 <p>
 To add a new GL extension to Mesa you have to do at least the following.
@@ -36,7 +36,7 @@ To add a new GL extension to Mesa you have to do at least the following.
    </pre>
 </li>
 <li>
-   In the src/mesa/glapi/ directory, add the new extension functions and
+   In the src/mapi/glapi/gen/ directory, add the new extension functions and
    enums to the gl_API.xml file.
    Then, a bunch of source files must be regenerated by executing the
    corresponding Python scripts.
@@ -155,6 +155,29 @@ of <tt>bool</tt>, <tt>true</tt>, and
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
 </p>
 
+<h2>Submitting patches</h2>
+
+<p>
+You should always run the Mesa Testsuite before submitting patches.
+The Testsuite can be run using the 'make check' command. All tests
+must pass before patches will be accepted, this may mean you have
+to update the tests themselves.
+</p>
+
+<p>
+Patches should be sent to the Mesa mailing list for review.
+When submitting a patch make sure to use git send-email rather than attaching
+patches to emails. Sending patches as attachments prevents people from being
+able to provide in-line review comments.
+</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>
 
 <h2>Marking a commit as a candidate for a stable branch</h2>
 
@@ -167,11 +190,26 @@ you should add an appropriate note to the commit message.
 Here are some examples of such a note:
 </p>
 <ul>
-  <li>NOTE: This is a candidate for the 9.0 branch.</li>
-  <li>NOTE: This is a candidate for the 8.0 and 9.0 branches.</li>
-  <li>NOTE: This is a candidate for the stable branches.</li>
+  <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.
+
+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
+patches to the mesa-dev@ mailing list. Also, if you realize that a commit
+should be nominated for the stable branch after it has already been committed,
+you can send a note directly to the mesa-stable@lists.freedesktop.org where
+the Mesa stable-branch maintainers will receive it. Be sure to mention the
+commit ID of the commit of interest (as it appears in the mesa master branch).
 
 <h2>Cherry-picking candidates for a stable branch</h2>