diff --git a/docs/devinfo.html b/docs/devinfo.html
index 8d20eea3c56..c7e4171a9cb 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -17,55 +17,15 @@
 <h1>Development Notes</h1>
 
 
-<h2>Adding Extensions</h2>
-
-<p>
-To add a new GL extension to Mesa you have to do at least the following.
-
 <ul>
-<li>
-   If glext.h doesn't define the extension, edit include/GL/gl.h and add
-   code like this:
-   <pre>
-     #ifndef GL_EXT_the_extension_name
-     #define GL_EXT_the_extension_name 1
-     /* declare the new enum tokens */
-     /* prototype the new functions */
-     /* TYPEDEFS for the new functions */
-     #endif
-   </pre>
-</li>
-<li>
-   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.
-</li>
-<li>
-   Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
-</li>
-<li>
-   Update the <code>extensions.c</code> file.
-</li>
-<li>
-   From this point, the best way to proceed is to find another extension,
-   similar to the new one, that's already implemented in Mesa and use it
-   as an example.
-</li>
-<li>
-   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>
-   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>
+<li><a href="#style">Coding Style</a>
+<li><a href="#submitting">Submitting Patches</a>
+<li><a href="#release">Making a New Mesa Release</a>
+<li><a href="#extensions">Adding Extensions</a>
 </ul>
 
 
-
-<h2>Coding Style</h2>
+<h2 id="style">Coding Style</h2>
 
 <p>
 Mesa's code style has changed over the years.  Here's the latest.
@@ -160,7 +120,8 @@ 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>
+
+<h2 id="submitting">Submitting patches</h2>
 
 <p>
 You should always run the Mesa Testsuite before submitting patches.
@@ -184,7 +145,7 @@ 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>
+<h3>Marking a commit as a candidate for a stable branch</h3>
 
 <p>
 If you want a commit to be applied to a stable branch,
@@ -221,7 +182,7 @@ the upcoming stable release can always be seen on the
 <a href="http://cworth.org/~cworth/mesa-stable-queue/">Mesa Stable Queue</a>
 page.
 
-<h2>Criteria for accepting patches to the stable branch</h2>
+<h3>Criteria for accepting patches to the stable branch</h3>
 
 Mesa has a designated release manager for each stable branch, and the release
 manager is the only developer that should be pushing changes to these
@@ -306,7 +267,8 @@ be rejected:
   regression that is unaacceptable for the stable branch.</li>
 </ul>
 
-<h2>Making a New Mesa Release</h2>
+
+<h2 id="release">Making a New Mesa Release</h2>
 
 <p>
 These are the instructions for making a new Mesa release.
@@ -543,6 +505,56 @@ release announcement:
 </pre>
 </p>
 
+
+<h2 id="extensions">Adding Extensions</h2>
+
+<p>
+To add a new GL extension to Mesa you have to do at least the following.
+
+<ul>
+<li>
+   If glext.h doesn't define the extension, edit include/GL/gl.h and add
+   code like this:
+   <pre>
+     #ifndef GL_EXT_the_extension_name
+     #define GL_EXT_the_extension_name 1
+     /* declare the new enum tokens */
+     /* prototype the new functions */
+     /* TYPEDEFS for the new functions */
+     #endif
+   </pre>
+</li>
+<li>
+   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.
+</li>
+<li>
+   Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
+</li>
+<li>
+   Update the <code>extensions.c</code> file.
+</li>
+<li>
+   From this point, the best way to proceed is to find another extension,
+   similar to the new one, that's already implemented in Mesa and use it
+   as an example.
+</li>
+<li>
+   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>
+   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>
+
+
+
+
 </div>
 </body>
 </html>