docs: fix small typos in the submit patches page
authorAndres Gomez <agomez@igalia.com>
Mon, 28 Nov 2016 16:47:42 +0000 (18:47 +0200)
committerEmil Velikov <emil.l.velikov@gmail.com>
Mon, 28 Nov 2016 17:46:12 +0000 (17:46 +0000)
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
docs/submittingpatches.html

index 2d18c74..3d07c5e 100644 (file)
@@ -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>