anv: fix alignments for uniform buffers

[mesa.git] / docs / submittingpatches.html

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 9113e417009a60dd5fa315cb3cbe120f35d2749a..15674291d08cddeed67edbe05811883aac83bf92 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>
@@ -373,9 +373,6 @@ If the patch complies with the rules it will be
 manager will reply to the patch in question stating why the patch has been
 rejected or would request a backport.
 
-A summary of all the picked/rejected patches will be presented in the
-<a href="releasing.html#prerelease">pre-release</a> announcement.
-
 The stable-release manager may at times need to force-push changes to the
 stable branches, for example, to drop a previously-picked patch that was later
 identified as causing a regression). These force-pushes may cause changes to
@@ -386,18 +383,19 @@ yourself warned.
 <p>
 By default merge conflicts are resolved by the stable-release manager. The
 release maintainer should resolve trivial conflicts, but for complex conflicts
-should ask the original author to provide a backport of de-nominate.
+they should ask the original author to provide a backport or de-nominate the
+patch.
 </p>
 
 <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>