docs: mention/suggest testing your patch against dEQP

[mesa.git] / docs / devinfo.html

diff --git a/docs/devinfo.html b/docs/devinfo.html
index eb3aba1364a9cd5df5460730354dc8b9ce88e93e..58025e661a1fcac8e377c0a123a98b4a17206652 100644 (file)
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -30,6 +30,12 @@
 <p>
 Mesa is over 20 years old and the coding style has evolved over time.
 Some old parts use a style that's a bit out of date.
+
+Different sections of mesa can use different coding style as set in the local
+EditorConfig (.editorconfig) and/or Emacs (.dir-locals.el) file.
+
+Alternatively the following is applicable.
+
 If the guidelines below don't cover something, try following the format of
 existing, neighboring code.
 </p>
@@ -244,18 +250,23 @@ to update the tests themselves.
 
 <p>
 Whenever possible and applicable, test the patch with
-<a href="http://people.freedesktop.org/~nh/piglit/">Piglit</a> to
-check for regressions.
+<a href="http://piglit.freedesktop.org">Piglit</a> and/or
+<a href="https://android.googlesource.com/platform/external/deqp/">dEQP</a>
+to check for regressions.
 </p>
 
 
 <h3>Mailing Patches</h3>
 
 <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.
+Patches should be sent to the mesa-dev mailing list for review:
+<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">
+mesa-dev@lists.freedesktop.org<a/>.
+When submitting a patch make sure to use
+<a href="https://git-scm.com/docs/git-send-email">git send-email</a>
+rather than attaching patches to emails. Sending patches as
+attachments prevents people from being able to provide in-line review
+comments.
 </p>
 
 <p>
@@ -266,6 +277,12 @@ re-sending the whole series). Using --in-reply-to makes
 it harder for reviewers to accidentally review old patches.
 </p>
 
+<p>
+When submitting follow-up patches you should also login to
+<a href="https://patchwork.freedesktop.org">patchwork</a> and change the
+state of your old patches to Superseded.
+</p>
+
 <h3>Reviewing Patches</h3>
 
 <p>
@@ -564,7 +581,7 @@ Edit docs/relnotes/X.Y.Z.html to add the sha256sums printed as part of "make
 tarballs" in the previous step. Commit this change.
 </p>
 
-<h3>Push all commits and the tag creates above</h3>
+<h3>Push all commits and the tag created above</h3>
 
 <p>
 This is the first step that cannot easily be undone. The release is going
@@ -591,7 +608,7 @@ signatures to the freedesktop.org server:
        mv ~/MesaLib-X.Y.Z* .
 </pre>
 
-<h3>Back on mesa master, andd the new release notes into the tree</h3>
+<h3>Back on mesa master, add the new release notes into the tree</h3>
 
 <p>
 Something like the following steps will do the trick:
@@ -678,9 +695,11 @@ To add a new GL extension to Mesa you have to do at least the following.
 </li>
 <li>
    Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
+   if the extension requires driver capabilities not already exposed by
+   another extension.
 </li>
 <li>
-   Update the <code>extensions.c</code> file.
+   Add a new entry to the src/mesa/main/extensions_table.h file.
 </li>
 <li>
    From this point, the best way to proceed is to find another extension,
@@ -691,12 +710,18 @@ To add a new GL extension to Mesa you have to do at least the following.
    If the new extension adds new GL state, the functions in get.c, enable.c
    and attrib.c will most likely require new code.
 </li>
+<li>
+   To determine if the new extension is active in the current context,
+   use the auto-generated _mesa_has_##name_str() function defined in
+   src/mesa/main/extensions.h.
+</li>
 <li>
    The dispatch tests check_table.cpp and dispatch_sanity.cpp
    should be updated with details about the new extensions functions. These
    tests are run using 'make check'
 </li>
 </ul>
+</p>