manuals: reduce verbosity related to "the following" expression

(From yocto-docs rev: da9d1cfb5c084d172eff3cb10ec3631dd8266260)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/README

@@ -167,7 +167,7 @@ The layout of the Yocto Project manuals is organized as follows
           Section
             Section
 
-The following headings styles are defined in Sphinx:
+Here are the heading styles defined in Sphinx:
 
     Book              => overline ===
       Chapter         => overline ***

documentation/dev-manual/common-tasks.rst

@@ -2513,7 +2513,7 @@ chapter of the BitBake User Manual.
    syntax, although access to OpenEmbedded variables and internal
    methods are also available.
 
-   The following is an example function from the ``sed`` recipe::
+   Here is an example function from the ``sed`` recipe::
 
       do_install () {
           autotools_do_install
@@ -7413,7 +7413,7 @@ The variable can contain multiple [one-line] metadata fields separated
 by the literal sequence '\\n'. The separator can be redefined using the
 variable flag ``separator``.
 
-The following is an example that adds two custom fields for ipk
+Here is an example that adds two custom fields for ipk
 packages::
 
    PACKAGE_ADD_METADATA_IPK = "Vendor: CustomIpk\nGroup:Applications/Spreadsheets"
@@ -7844,7 +7844,7 @@ Build history information is kept in
 ``${``\ :term:`TOPDIR`\ ``}/buildhistory``
 in the Build Directory as defined by the
 :term:`BUILDHISTORY_DIR`
-variable. The following is an example abbreviated listing:
+variable. Here is an example abbreviated listing:
 
 .. image:: figures/buildhistory.png
    :align: center
@@ -11058,7 +11058,7 @@ this function, you have to follow the following steps:
 3. Meta-spdxscanner provides several methods within the bbclass to create spdx files.
    Please choose one that you want to use and enable the spdx task. You have to
    add some config options in ``local.conf`` file in your :term:`Build
-   Directory`. The following is an example showing how to generate spdx files
+   Directory`. Here is an example showing how to generate spdx files
    during bitbake using the fossology-python.bbclass::
 
       # Select fossology-python.bbclass.
@@ -11088,7 +11088,7 @@ package, by using the
 variable. Using this variable also avoids QA errors when you use a
 non-common, non-CLOSED license in a recipe.
 
-The following is an example that uses the ``LICENSE.Abilis.txt`` file as
+Here is an example that uses the ``LICENSE.Abilis.txt`` file as
 the license from the fetched source::
 
    NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"

documentation/dev-manual/qemu.rst

@@ -219,15 +219,15 @@ using an NFS server.
    Should you need to start, stop, or restart the NFS share, you can use
    the following commands:
 
-   -  The following command starts the NFS share::
+   -  To start the NFS share::
 
          runqemu-export-rootfs start file-system-location
 
-   -  The following command stops the NFS share::
+   -  To stop the NFS share::
 
          runqemu-export-rootfs stop file-system-location
 
-   -  The following command restarts the NFS share::
+   -  To restart the NFS share::
 
          runqemu-export-rootfs restart file-system-location
 

documentation/kernel-dev/common.rst

@@ -338,7 +338,7 @@ section:
    the ``yocto-4.12`` branch.
 
    The following commands show how to create a local copy of the
-   ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch::
+   ``yocto-kernel-cache`` and switch to the ``yocto-4.12`` branch::
 
       $ cd ~
       $ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12
@@ -491,7 +491,7 @@ As an example, consider the following append file used by the BSPs in
 
    meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
 
-The following listing shows the file. Be aware that the actual commit ID
+Here are the contents of this file. Be aware that the actual commit ID
 strings in this example listing might be different than the actual
 strings in the file from the ``meta-yocto-bsp`` layer upstream.
 ::

documentation/kernel-dev/concepts-appx.rst

@@ -379,8 +379,7 @@ or non-hardware. To better show this, consider a situation where the
    yocto-kernel-cache/ktypes/base/hardware.kcf
    yocto-kernel-cache/bsp/qemu-ppc32/hardware.kcf
 
-The following list
-provides explanations for the various files:
+Here are explanations for the various files:
 
 -  ``hardware.kcf``: Specifies a list of kernel Kconfig files that
    contain hardware options only.

documentation/kernel-dev/faq.rst

@@ -7,7 +7,7 @@ Kernel Development FAQ
 Common Questions and Solutions
 ==============================
 
-The following lists some solutions for common questions.
+Here are some solutions for common questions.
 
 How do I use my own Linux kernel ``.config`` file?
 --------------------------------------------------

documentation/overview-manual/intro.rst

@@ -12,7 +12,7 @@ introduces the Yocto Project by providing concepts, software overviews,
 best-known-methods (BKMs), and any other high-level introductory
 information suitable for a new Yocto Project user.
 
-The following list describes what you can get from this manual:
+Here is what you can get from this manual:
 
 -  :ref:`overview-manual/yp-intro:introducing the yocto project`\ *:*
    This chapter provides an introduction to the Yocto Project. You will learn

documentation/overview-manual/yp-intro.rst

@@ -38,8 +38,7 @@ to the Yocto Project.
 Features
 --------
 
-The following list describes features and advantages of the Yocto
-Project:
+Here are features and advantages of the Yocto Project:
 
 -  *Widely Adopted Across the Industry:* Many semiconductor, operating
    system, software, and service vendors adopt and support the Yocto
@@ -137,8 +136,7 @@ Project:
 Challenges
 ----------
 
-The following list presents challenges you might encounter when
-developing using the Yocto Project:
+Here are challenges you might encounter when developing using the Yocto Project:
 
 -  *Steep Learning Curve:* The Yocto Project has a steep learning curve
    and has many different ways to accomplish similar tasks. It can be
@@ -292,8 +290,8 @@ associated with the Yocto Project.
 Development Tools
 -----------------
 
-The following list consists of tools that help you develop images and
-applications using the Yocto Project:
+Here are tools that help you develop images and applications using
+the Yocto Project:
 
 -  *CROPS:* `CROPS <https://github.com/crops/poky-container/>`__ is an
    open source, cross-platform development framework that leverages
@@ -347,8 +345,8 @@ applications using the Yocto Project:
 Production Tools
 ----------------
 
-The following list consists of tools that help production related
-activities using the Yocto Project:
+Here are tools that help with production related activities using the
+Yocto Project:
 
 -  *Auto Upgrade Helper:* This utility when used in conjunction with the
    :term:`OpenEmbedded Build System`
@@ -444,8 +442,7 @@ activities using the Yocto Project:
 Open-Embedded Build System Components
 -------------------------------------
 
-The following list consists of components associated with the
-:term:`OpenEmbedded Build System`:
+Here are components associated with the :term:`OpenEmbedded Build System`:
 
 -  *BitBake:* BitBake is a core component of the Yocto Project and is
    used by the OpenEmbedded build system to build images. While BitBake
@@ -511,8 +508,7 @@ section.
 Packages for Finished Targets
 -----------------------------
 
-The following lists components associated with packages for finished
-targets:
+Here are components associated with packages for finished targets:
 
 -  *Matchbox:* Matchbox is an Open Source, base environment for the X
    Window System running on non-desktop, embedded platforms such as

documentation/ref-manual/classes.rst

@@ -1009,7 +1009,7 @@ Please keep in mind that the QA checks
 exist in order to detect real or potential problems in the packaged
 output. So exercise caution when disabling these checks.
 
-The following list shows the tests you can list with the ``WARN_QA`` and
+Here are the tests you can list with the ``WARN_QA`` and
 ``ERROR_QA`` variables:
 
 -  ``already-stripped:`` Checks that produced binaries have not

documentation/ref-manual/features.rst

@@ -196,7 +196,7 @@ you can add several different predefined packages such as development
 utilities or packages with debug information needed to investigate
 application problems or profile applications.
 
-The following image features are available for all images:
+Here are the image features available for all images:
 
 -  *allow-empty-password:* Allows Dropbear and OpenSSH to accept root
    logins and logins from accounts having an empty password string.

documentation/ref-manual/system-requirements.rst

@@ -111,7 +111,7 @@ function.
 Ubuntu and Debian
 -----------------
 
-The following list shows the required packages by function given a
+Here are the required packages by function given a
 supported Ubuntu or Debian Linux distribution:
 
 .. note::
@@ -150,7 +150,7 @@ supported Ubuntu or Debian Linux distribution:
 Fedora Packages
 ---------------
 
-The following list shows the required packages by function given a
+Here are the required packages by function given a
 supported Fedora Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
@@ -167,7 +167,7 @@ supported Fedora Linux distribution:
 openSUSE Packages
 -----------------
 
-The following list shows the required packages by function given a
+Here are the required packages by function given a
 supported openSUSE Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
@@ -185,7 +185,7 @@ supported openSUSE Linux distribution:
 CentOS-7 Packages
 -----------------
 
-The following list shows the required packages by function given a
+Here are the required packages by function given a
 supported CentOS-7 Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless
@@ -212,7 +212,7 @@ supported CentOS-7 Linux distribution:
 CentOS-8 Packages
 -----------------
 
-The following list shows the required packages by function given a
+Here are the required packages by function given a
 supported CentOS-8 Linux distribution:
 
 -  *Essentials:* Packages needed to build an image for a headless

documentation/ref-manual/variables.rst

@@ -4754,7 +4754,7 @@ system and gives an overview of their function and contents.
 
          NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source"
 
-      The following is an example that
+      Here is an example that
       uses the ``LICENSE.Abilis.txt`` file as the license from the fetched
       source::
 

documentation/toaster-manual/reference.rst

@@ -186,7 +186,7 @@ Configuring the Workflow
 ------------------------
 
 The ``bldcontrol/management/commands/checksettings.py`` file controls
-workflow configuration. The following steps outline the process to
+workflow configuration. Here is the process to
 initially populate this database.
 
 1. The default project settings are set from
@@ -237,7 +237,7 @@ The following example sets "name" to "CUSTOM_XML_ONLY" and its value to
 Understanding Fixture File Format
 ---------------------------------
 
-The following is an overview of the file format used by the
+Here is an overview of the file format used by the
 ``oe-core.xml``, ``poky.xml``, and ``custom.xml`` files.
 
 The following subsections describe each of the sections in the fixture
@@ -407,7 +407,7 @@ To get the status of pending builds, use the following call::
 Be sure to provide values for host and port. The output is a JSON file that
 itemizes all builds in progress. This file includes the time in seconds since
 each respective build started as well as the progress of the cloning, parsing,
-and task execution. The following is sample output for a build in progress:
+and task execution. Here is sample output for a build in progress:
 
 .. code-block:: JSON
 
@@ -440,8 +440,8 @@ call::
    http://host:port/toastergui/api/builds
 
 Be sure to provide values for host and port. The output is a JSON file that
-itemizes all complete builds, and includes build summary information. The
-following is sample output for a completed build:
+itemizes all complete builds, and includes build summary information. Here
+is sample output for a completed build:
 
 .. code-block:: JSON
 
@@ -479,7 +479,7 @@ Completed query. See the ":ref:`toaster-manual/reference:checking status of buil
 section for more information.
 
 The output is a JSON file that itemizes the specific build and includes
-build summary information. The following is sample output for a specific
+build summary information. Here is sample output for a specific
 build:
 
 .. code-block:: JSON