freedreno/resource: fail more gracefully
[mesa.git] / docs / devinfo.html
index bd11e5ccc1fa0dce764336aadd4b56e9a132ec3e..b495097c9d0db7d88a468f20671e6825d10e4dc8 100644 (file)
@@ -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>
 
@@ -193,15 +216,7 @@ branch is relevant.
 </p>
 
 
-<h3>Verify and update version info</h3>
-
-<dl>
-  <dt>SConstruct</dt>
-  <dt>Android.common.mk</dt>
-  <dd>PACKAGE_VERSION</dd>
-  <dt>configure.ac</dt>
-  <dd>AC_INIT</dd>
-</dl>
+<h3>Verify and update version info in VERSION</h3>
 
 <p>
 Create a docs/relnotes/x.y.z.html file.