Prefer the full url to just ``Closes: #1``, since the url makes it
easier to get to the bug page from ``git log``
- **Do not use the Fixes: tag for this!** Mesa already uses Fixes for
- something else.
-
-- If a patch addresses a issue introduced with earlier commit, that
- should be noted in the patch comment. For example:
-
- ::
-
- Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
-
-- You can produce those fixes lines by running
-
- ::
-
- git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"
-
- once and then using
-
- ::
-
- git fixes <sha1>
+ **Do not use the ``Fixes:`` tag for this!** Mesa already uses
+ ``Fixes:`` for something else.
+ See `below <#fixes>`__.
- If there have been several revisions to a patch during the review
process, they should be noted such as in this example:
This provides reviewers with quick feedback if the patch has already
been reviewed.
+.. _fixes:
+
+The ``Fixes:`` tag
+------------------
+
+If a patch addresses a issue introduced with earlier commit, that
+should be noted in the commit message. For example::
+
+ Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
+
+You can produce those fixes lines by running this command once::
+
+ git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"
+
+After that, using ``git fixes <sha1>`` will print the full line for you.
+
+The stable tag
+~~~~~~~~~~~~~~
+
+If you want a commit to be applied to a stable branch, you should add an
+appropriate note to the commit message.
+
+Using a ``Fixes:`` tag as described in `Patch formatting <#formatting>`__
+is the preferred way to nominate a commit that 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.
+
+Alternatively, you may use a "CC:" tag. Here are some examples of such a
+note::
+
+ CC: 20.0 19.3 <mesa-stable>
+
+Using the CC tag **should** 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.
+
.. _testing:
Testing Patches
There are several ways to nominate a patch for inclusion in the stable
branch and release. In order or preference:
-- By adding the ``Fixes:`` tag as described above, if you are fixing
+- By adding the ``Fixes:`` tag in the commit message as described above, if you are fixing
a specific commit.
-- By adding the ``Cc: mesa-stable`` tag as described below.
-- By submitting a merge request against the "staging/year.quarter"
- branch on gitlab.
+- By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
+- By submitting a merge request against the ``staging/year.quarter``
+ branch on gitlab.
Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
is not monitored actively and is a historical artifact.
The current patch status can be observed in the `staging
branch <releasing.rst#stagingbranch>`__.
-The stable tag
-~~~~~~~~~~~~~~
-
-If you want a commit to be applied to a stable branch, you should add an
-appropriate note to the commit message.
-
-Using a "fixes tag" as described in `Patch formatting <#formatting>`__
-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.
-
-Alternatively, you may use a "CC:" tag. Here are some examples of such a
-note:
-
-::
-
- CC: 20.0 19.3 <mesa-stable>
-
-Using the CC tag **should** 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.
-
.. _criteria:
Criteria for accepting patches to the stable branch
projects / mesa.git / blobdiff