diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/submittingpatches.html | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index 2d18c74decf..3d07c5e96d4 100644 --- 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 <commit></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> |