components.
- Patches should never introduce build breaks and should be bisectable
(see ``git bisect``.)
-- Patches should be properly `formatted <#formatting>`__.
-- Patches should be sufficiently `tested <#testing>`__ before
+- Patches should be properly :ref:`formatted <formatting>`.
+- Patches should be sufficiently :ref:`tested <testing>` before
submitting.
-- Patches should be `submitted <#submit>`__ via a merge request for
- `review <#reviewing>`__.
+- Patches should be :ref:`submitted <submit>` via a merge request for
+ :ref:`review <reviewing>`.
.. _formatting:
**Do not use the ``Fixes:`` tag for this!** Mesa already uses
``Fixes:`` for something else.
- See `below <#fixes>`__.
+ See :ref:`below <fixes>`.
- If there have been several revisions to a patch during the review
process, they should be noted such as in this example:
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>`__
+Using a ``Fixes:`` tag as described in :ref:`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.
If you are not the author of the original patch, please Cc: them in your
nomination request.
-The current patch status can be observed in the `staging
-branch <releasing.rst#stagingbranch>`__.
+The current patch status can be observed in the :ref:`staging
+branch <stagingbranch>`.
.. _criteria:
accepted and which are not. The stable-release manager is also given
broad discretion in rejecting patches that have been nominated.
-- Patch must conform with the `Basic guidelines <#guidelines>`__
+- Patch must conform with the :ref:`Basic guidelines <guidelines>`
- Patch must have landed in master first. In case where the original
patch is too large and/or otherwise contradicts with the rules set
within, a backport is appropriate.
.. note::
An exception to this rule, are hardware-enabling "features". For
- example, `backports <#backports>`__ of new code to support a
+ example, :ref:`backports <backports>` of new code to support a
newly-developed hardware product can be accepted if they can be
reasonably determined not to have effects on other hardware.