docs: fix small typos in the submit patches page

Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 2d18c74decfc9fb11a9468d39c8389eaed70dfe0..3d07c5e96d41948a8819cbc55c971be4eb46aa79 100644 (file)
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -41,7 +41,7 @@ components.
 <code>git bisect</code>.)
 <li>Patches should be properly <a href="#formatting">formatted</a>.
 <li>Patches should be sufficiently <a href="#testing">tested</a> before submitting.
-<li>Patches should be submitted to <a href="#mailing">submitted to mesa-dev</a>
+<li>Patches should be submitted to <a href="#mailing">mesa-dev</a>
 for <a href="#reviewing">review</a> using <code>git send-email</code>.
 
 </ul>
@@ -254,9 +254,9 @@ branches. Everyone else should simply nominate patches using the mechanism
 described above.
 
 The stable-release manager will work with the list of nominated patches, and
-for each patch that meets the crtieria below will cherry-pick the patch with:
+for each patch that meets the criteria below will cherry-pick the patch with:
 <code>git cherry-pick -x &lt;commit&gt;</code>. The <code>-x</code> option is
-important so that the picked patch references the comit ID of the original
+important so that the picked patch references the commit ID of the original
 patch.
 
 The stable-release manager may at times need to force-push changes to the
@@ -328,7 +328,7 @@ be rejected:
   release. The potential problem here is that an OpenGL program that was
   previously working, (even if technically non-compliant with the
   specification), could stop working after this patch. So that would be a
-  regression that is unaacceptable for the stable branch.</li>
+  regression that is unacceptable for the stable branch.</li>
 </ul>
 
 <h2 id="gittips">Git tips</h2>