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:
Reviewed-by: Joe Hacker <jhacker@foo.com>
Acked-by: Joe Hacker <jhacker@foo.com>
-- If sending later revision of a patch, add all the tags - ack, r-b,
- Cc: mesa-stable and/or other. This provides reviewers with quick
- feedback if the patch has already been reviewed.
+- When updating a merge request add all the tags (``Acked-by:``, ``Reviewed-by:``,
+ ``Fixes:``, ``Cc: mesa-stable`` and/or other) to the commit messages.
+ 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:
Nominating a commit for a stable branch
---------------------------------------
-There are three ways to nominate a patch for inclusion in the stable
-branch and release.
+There are several ways to nominate a patch for inclusion in the stable
+branch and release. In order or preference:
-- By adding the Cc: mesa-stable@ tag as described below.
-- By adding the fixes: tag as described below.
-- By submitting a merge request against the "staging/year.quarter"
- branch on gitlab.
+- 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 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@lists.freedesktop.org>
-
-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
.. code-block:: console
git rebase -i --exec="ninja -C build/" HEAD~8
-
-- Sets the default mailing address for your repo.
-
- .. code-block:: console
-
- git config --local sendemail.to mesa-dev@lists.freedesktop.org
-
-- Add version to subject line of patch series in this case for the last
- 8 commits before sending.
-
- .. code-block:: console
-
- git send-email --subject-prefix="PATCH v4" HEAD~8
- git send-email -v4 @~8 # shorter version, inherited from git format-patch
projects / mesa.git / blobdiff