docs/devel: clean-up the CI links in the docs

There where some broken links so fix those up with proper references
to the devel docs. I also did a little light copy-editing to reflect
the current state and broke up a paragraph to reduce the "wall of
text" effect.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220527153603.887929-34-alex.bennee@linaro.org>

docs/devel/ci-jobs.rst.inc

@@ -1,3 +1,5 @@
+.. _ci_var:
+
 Custom CI/CD variables
 ======================
 

docs/devel/ci.rst

@@ -1,12 +1,13 @@
+.. _ci:
+
 ==
 CI
 ==
 
-QEMU has configurations enabled for a number of different CI services.
+Most of QEMU's CI is run on GitLab's infrastructure although a number
-The most up to date information about them and their status can be
+of other CI services are used for specialised purposes. The most up to
-found at::
+date information about them and their status can be found on the
-
+`project wiki testing page <https://wiki.qemu.org/Testing/CI>`_.
-   https://wiki.qemu.org/Testing/CI
 
 .. include:: ci-definitions.rst.inc
 .. include:: ci-jobs.rst.inc

docs/devel/submitting-a-patch.rst

@@ -204,23 +204,25 @@ log`` for these keywords for example usage.
 Test your patches
 ~~~~~~~~~~~~~~~~~
 
-Although QEMU has `continuous integration
+Although QEMU uses various :ref:`ci` services that attempt to test
-services <Testing#Continuous_Integration>`__ that attempt to test
+patches submitted to the list, it still saves everyone time if you
-patches submitted to the list, it still saves everyone time if you have
+have already tested that your patch compiles and works. Because QEMU
-already tested that your patch compiles and works. Because QEMU is such
+is such a large project the default configuration won't create a
-a large project, it's okay to use configure arguments to limit what is
+testing pipeline on GitLab when a branch is pushed. See the :ref:`CI
-built for faster turnaround during your development time; but it is
+variable documentation<ci_var>` for details on how to control the
-still wise to also check that your patches work with a full build before
+running of tests; but it is still wise to also check that your patches
-submitting a series, especially if your changes might have an unintended
+work with a full build before submitting a series, especially if your
-effect on other areas of the code you don't normally experiment with.
+changes might have an unintended effect on other areas of the code you
-See `Testing <Testing>`__ for more details on what tests are available.
+don't normally experiment with. See :ref:`testing` for more details on
-Also, it is a wise idea to include a testsuite addition as part of your
+what tests are available.
-patches - either to ensure that future changes won't regress your new
+
-feature, or to add a test which exposes the bug that the rest of your
+Also, it is a wise idea to include a testsuite addition as part of
-series fixes. Keeping separate commits for the test and the fix allows
+your patches - either to ensure that future changes won't regress your
-reviewers to rebase the test to occur first to prove it catches the
+new feature, or to add a test which exposes the bug that the rest of
-problem, then again to place it last in the series so that bisection
+your series fixes. Keeping separate commits for the test and the fix
-doesn't land on a known-broken state.
+allows reviewers to rebase the test to occur first to prove it catches
+the problem, then again to place it last in the series so that
+bisection doesn't land on a known-broken state.
 
 .. _submitting_your_patches:
 

docs/devel/testing.rst

@@ -1,3 +1,5 @@
+.. _testing:
+
 Testing in QEMU
 ===============