<p>
Whenever possible and applicable, test the patch with
-<a href="http://people.freedesktop.org/~nh/piglit/">Piglit</a> to
+<a href="http://piglit.freedesktop.org">Piglit</a> to
check for regressions.
</p>
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>
+When you've reviewed a patch on the mailing list, please be unambiguous
+about your review. That is, state either
+<pre>
+ Reviewed-by: Joe Hacker <jhacker@foo.com>
+</pre>
+or
+<pre>
+ Acked-by: Joe Hacker <jhacker@foo.com>
+</pre>
+Rather than saying just "LGTM" or "Seems OK".
+</p>
+
+<p>
+If small changes are suggested, it's OK to say something like:
+<pre>
+ With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
+</pre>
+which tells the patch author that the patch can be committed, as long
+as the issues are resolved first.
+</p>
+
+
<h3>Marking a commit as a candidate for a stable branch</h3>
<p>
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
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: