docs: Update stable process around using fixes: and gitlab

Currently the docs still recommend using
mesa-stable@lists.freedesktop.org, which is pretty awful. We really
don't want a second mailing list and it's mostly full of junk because of
CC: tags anyway.

This changes the preferred actions to be:
1) use a fixes: tag ahead of time
2) use a Cc tag ahead of time if fixes isn't appropriate
3) Use a gitlab MR against the staging/ branch for post-merge/backport
   nominations

Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3056>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3056>

1 files changed, 30 insertions, 28 deletions

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 97fae5484a3..9113e417009 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -278,13 +278,14 @@ release.
 </p>
 <ul>
 <li> By adding the Cc: mesa-stable@ tag as described below.
-<li> Sending the commit ID (as seen in master branch) to the mesa-stable@ mailing list.
-<li> Forwarding the patch from the mesa-dev@ mailing list.
+<li> By adding the fixes: tag as described below.
+<li> By submitting a merge requestion against the "staging/year.quarter" branch on gitlab.
 </li>
 </ul>
 <p>
-Note: resending patch identical to one on mesa-dev@ or one that differs only
-by the extra mesa-stable@ tag is <strong>not</strong> recommended.
+Please <strong>DO NOT</strong> send patches to
+mesa-stable@lists.freedektop.org, it is not monitored actively and is a
+historical artifact.
 </p>
 <p>
 If you are not the author of the original patch, please Cc: them in your
@@ -303,31 +304,27 @@ you should add an appropriate note to the commit message.
 </p>
 
 <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
+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.
+
 Here are some examples of such a note:
 </p>
 <pre>
-CC: &lt;mesa-stable@lists.freedesktop.org&gt;
+CC: 20.0 19.3 &lt;mesa-stable@lists.freedesktop.org&gt;
 </pre>
 
-Simply adding the CC to the mesa-stable list address is adequate to nominate
-the commit for all the active stable branches. If the commit is not applicable
-for said branch the stable-release manager will reply stating so.
-
-This "CC" syntax for patch nomination will cause patches to automatically be
-copied to the mesa-stable@ mailing list when you use "git send-email" to send
-patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that
-won't have any negative effect on the patch nomination.
-
 <p>
-Note: by removing the tag [as the commit is pushed] the patch is
-<strong>explicitly</strong> rejected from inclusion in the stable branch(es).
-Thus, drop the line <strong>only</strong> if you want to cancel the nomination.
+Using the CC tag <strong>should</strong> include the stable branches you want
+to nominate the patch to. If you do not provide any version it is nominated to
+all active stable branches.
 </p>
 
-Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting"
-section, it nominates a commit for all active stable branches that include the
-commit that is referred to.
-
 <h2 id="criteria">Criteria for accepting patches to the stable branch</h2>
 
 Mesa has a designated release manager for each stable branch, and the release
@@ -387,16 +384,21 @@ yourself warned.
 
 <h2 id="backports">Sending backports for the stable branch</h2>
 <p>
-By default merge conflicts are resolved by the stable-release manager. In which
-case he/she should provide a comment about the changes required, alongside the
-<code>Conflicts</code> section. Summary of which will be provided in the
-<a href="releasing.html#prerelease">pre-release</a> announcement.
+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.
 </p>
 
 <p>
-Developers are interested in sending backports are recommended to use either a
-<code>[BACKPORT #branch]</code> subject prefix or provides similar information
-within the commit summary.
+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.
+
+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
+helpful, but not required.
 </p>
 
 <h2 id="gittips">Git tips</h2>