docs: fix typos in the release docs

Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Andres Gomez <agomez@igalia.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4067>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4067>

diff --git a/docs/releasing.html b/docs/releasing.html
index 15ec38a37719b8a87c5ae8b92fa767d338897eaf..2223472408c63787af98e27b17c5599f4c5708c0 100644 (file)
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -381,7 +381,7 @@ git cherry-pick -x X.Y~1
 git cherry-pick -x X.Y
 </pre>
 
-<p>Then run the <pre>./bin/post_verison.py X.Y.Z</pre>, where X.Y.Z is the
+<p>Then run the <pre>./bin/post_version.py X.Y.Z</pre>, where X.Y.Z is the
 version you just made. This will updated docs/relnotes.html,
 docs/index.html, and docs/release-calendar.html. It will then generate
 a git commit automatically. Check that everything looks correct and push:
@@ -407,7 +407,7 @@ series, if that is the case.
 <h2 id="gitlab">Update gitlab issues</h2>
 
 <p>
-Parse through the bugreports as listed in the docs/relnotes/X.Y.Z.html
+Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.html
 document. If there's outstanding action, close the bug referencing the commit
 ID which addresses the bug and mention the Mesa version that has the fix.
 </p>

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 7378dda6b830bb3cd51ed3a526575f7c79f8ac3a..0f8bcb3284e11edb29816a414b396a32f1197971 100644 (file)
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -146,7 +146,7 @@ to check for regressions.
 </p>
 
 <p>
-As mentioned at the begining, patches should be bisectable.
+As mentioned at the beginning, patches should be bisectable.
 A good way to test this is to make use of the `git rebase` command,
 to run your tests on each commit. Assuming your branch is based off
 <code>origin/master</code>, you can run:
@@ -279,12 +279,12 @@ release.
 <ul>
 <li> By adding the Cc: mesa-stable@ tag as described below.
 <li> By adding the fixes: tag as described below.
-<li> By submitting a merge requestion against the "staging/year.quarter" branch on gitlab.
+<li> By submitting a merge request against the "staging/year.quarter" branch on gitlab.
 </li>
 </ul>
 <p>
 Please <strong>DO NOT</strong> send patches to
-mesa-stable@lists.freedektop.org, it is not monitored actively and is a
+mesa-stable@lists.freedesktop.org, it is not monitored actively and is a
 historical artifact.
 </p>
 <p>
@@ -305,13 +305,13 @@ you should add an appropriate note to the commit message.
 
 <p>
 Using a "fixes tag" as described in <a href="#formatting">Patch formatting</a>
-is the prefered way to nominate a commit that you know ahead of time should be
+is the preferred way to nominate a commit that you know ahead of time should be
 backported. There are scripts that will figure out which releases to apply the
 patch to automatically, so you don't need to figure it out.
 </p>
 
 <p>
-Alternatively, you maye use a "CC:" tag.
+Alternatively, you may use a "CC:" tag.
 
 Here are some examples of such a note:
 </p>
@@ -393,12 +393,12 @@ patch.
 <p>
 For patches that either need to be nominated after they've landed in master, or
 that are known ahead of time to not not apply cleanly to a stable branch (such
-as due to a rename), using a gitlab MR is most appropirate.
+as due to a rename), using a gitlab MR is most appropriate.
 
 The MR should be based on and target the staging/year.quarter branch, not on
 the year.quarter branch, per the stable branch policy.
 
-Assinging the MR to release maintainer for said branch or mentioning them is
+Assigning the MR to release maintainer for said branch or mentioning them is
 helpful, but not required.
 </p>