diff options
| author | Erik Faye-Lund <[email protected]> | 2020-06-27 10:00:10 +0200 |
|---|---|---|
| committer | Marge Bot <[email protected]> | 2020-06-28 09:06:57 +0000 |
| commit | b1c16e52514fd9e66d3ac118f1ec32a83cbc5f2a (patch) | |
| tree | a641fd181f68e65d7c1a581587f6db379857189c /docs/submittingpatches.rst | |
| parent | 5ee55b206af1a2eaf5ad23c8b8833c6fc49a96ea (diff) | |
docs: use ref-links for internal references
Ref-link have two benefits over generic links:
1. They produce the right result for non-HTML outputs
2. They get validated at build-time
So let's use them for internal references instead.
Reviewed-by: Eric Engestrom <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5671>
Diffstat (limited to 'docs/submittingpatches.rst')
| -rw-r--r-- | docs/submittingpatches.rst | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/docs/submittingpatches.rst b/docs/submittingpatches.rst index e51105dc22f..98398d972ab 100644 --- a/docs/submittingpatches.rst +++ b/docs/submittingpatches.rst @@ -14,11 +14,11 @@ Basic guidelines 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: @@ -64,7 +64,7 @@ Patch 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: @@ -126,7 +126,7 @@ 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>`__ +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. @@ -286,8 +286,8 @@ is not monitored actively and is a historical artifact. 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: @@ -301,7 +301,7 @@ mechanism described above. The following rules define which patches are 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. @@ -319,7 +319,7 @@ broad discretion in rejecting patches that have been nominated. .. 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. |