docs: submitting-patches: use :doc: for references

There are two broken references at submitting-patches.rst:

	Documentation/process/submitting-patches.rst:240: WARNING: undefined label: security-bugs (if the link has no caption the label must precede a section header)
	Documentation/process/submitting-patches.rst:336: WARNING: undefined label: documentation/process/email-clients.rst (if the link has no caption the label must precede a section header)

Those are due to some recent renames and file moves.

It turns that maintaining :ref: is currently harder than using
:doc:, as we now have a script to help checking such references.

So, replace :ref: to :doc: there, making them to point to the
current file name.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/3ba405f579cf35ef2b39dd210d8ad46adc79f0ad.1599660067.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Mauro Carvalho Chehab
2020-09-09 16:10:54 +02:00
committed by Jonathan Corbet
parent b899353d22
commit 5ff4aa70bf

View File

@@ -10,13 +10,10 @@ can greatly increase the chances of your change being accepted.
This document contains a large number of suggestions in a relatively terse This document contains a large number of suggestions in a relatively terse
format. For detailed information on how the kernel development process format. For detailed information on how the kernel development process
works, see :ref:`Documentation/process <development_process_main>`. works, see :doc:`development-process`. Also, read :doc:`submit-checklist`
Also, read :ref:`Documentation/process/submit-checklist.rst <submitchecklist>` for a list of items to check before submitting code. If you are submitting
for a list of items to check before a driver, also read :doc:`submitting-drivers`; for device tree binding patches,
submitting code. If you are submitting a driver, also read read :doc:`submitting-patches`.
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`;
for device tree binding patches, read
Documentation/devicetree/bindings/submitting-patches.rst.
This documentation assumes that you're using ``git`` to prepare your patches. This documentation assumes that you're using ``git`` to prepare your patches.
If you're unfamiliar with ``git``, you would be well-advised to learn how to If you're unfamiliar with ``git``, you would be well-advised to learn how to
@@ -241,7 +238,7 @@ If you have a patch that fixes an exploitable security bug, send that patch
to security@kernel.org. For severe bugs, a short embargo may be considered to security@kernel.org. For severe bugs, a short embargo may be considered
to allow distributors to get the patch out to users; in such cases, to allow distributors to get the patch out to users; in such cases,
obviously, the patch should not be sent to any public lists. See also obviously, the patch should not be sent to any public lists. See also
:ref:`Documentation/admin-guide/security-bugs.rst <security-bugs>`. :doc:`/admin-guide/security-bugs`.
Patches that fix a severe bug in a released kernel should be directed Patches that fix a severe bug in a released kernel should be directed
toward the stable maintainers by putting a line like this:: toward the stable maintainers by putting a line like this::
@@ -313,9 +310,8 @@ decreasing the likelihood of your MIME-attached change being accepted.
Exception: If your mailer is mangling patches then someone may ask Exception: If your mailer is mangling patches then someone may ask
you to re-send them using MIME. you to re-send them using MIME.
See :ref:`Documentation/process/email-clients.rst <email_clients>` See :doc:`/process/email-clients` for hints about configuring your e-mail
for hints about configuring your e-mail client so that it sends your patches client so that it sends your patches untouched.
untouched.
Respond to review comments Respond to review comments
-------------------------- --------------------------
@@ -333,7 +329,7 @@ for their time. Code review is a tiring and time-consuming process, and
reviewers sometimes get grumpy. Even in that case, though, respond reviewers sometimes get grumpy. Even in that case, though, respond
politely and address the problems they have pointed out. politely and address the problems they have pointed out.
See :ref:`Documentation/process/email-clients.rst` for recommendations on email See :doc:`email-clients` for recommendations on email
clients and mailing list etiquette. clients and mailing list etiquette.