<li>If a patch addresses an issue in gitlab, use the Closes: tag
For example:
<pre>
-Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
+Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1
</pre>
<p>Prefer the full url to just <code>Closes: #1</code>, since the url makes it
easier to get to the bug page from <code>git log</code></p>
</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:
<p>
To participate in code review, you can monitor the GitLab Mesa
- <a href="https://gitlab.freedesktop.org/mesa/mesa/merge_requests">Merge
+ <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests">Merge
Requests</a> page, and/or register for notifications in your gitlab
settings.
</p>
</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 request 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.freedesktop.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
</p>
<p>
+Using a "fixes tag" as described in <a href="#formatting">Patch formatting</a>
+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 may use a "CC:" tag.
+
Here are some examples of such a note:
</p>
<pre>
-CC: <mesa-stable@lists.freedesktop.org>
+CC: 20.0 19.3 <mesa-stable@lists.freedesktop.org>
</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
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
<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
+they should ask the original author to provide a backport or de-nominate the
+patch.
</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 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.
+
+Assigning the MR to release maintainer for said branch or mentioning them is
+helpful, but not required.
</p>
<h2 id="gittips">Git tips</h2>
projects / mesa.git / blobdiff