diff --git a/poky/documentation/.gitignore b/poky/documentation/.gitignore
index 21bb725..c44580b 100644
--- a/poky/documentation/.gitignore
+++ b/poky/documentation/.gitignore
@@ -1,2 +1,3 @@
 _build/
 Pipfile.lock
+.vscode/
diff --git a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/poky/documentation/brief-yoctoprojectqs/index.rst
similarity index 91%
rename from poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
rename to poky/documentation/brief-yoctoprojectqs/index.rst
index c9622d3..f077ee8 100644
--- a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/poky/documentation/brief-yoctoprojectqs/index.rst
@@ -20,7 +20,7 @@
       (:term:`Build Host`) is not
       a native Linux system, you can still perform these steps by using
       CROss PlatformS (CROPS) and setting up a Poky container. See the
-      :ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`
+      :ref:`dev-manual/start:setting up to use cross platforms (crops)`
       section
       in the Yocto Project Development Tasks Manual for more
       information.
@@ -34,12 +34,12 @@
          compatible but not officially supported nor validated with
          WSLv2, if you still decide to use WSL please upgrade to WSLv2.
 
-      See the :ref:`dev-manual/dev-manual-start:setting up to use windows
+      See the :ref:`dev-manual/start:setting up to use windows
       subsystem for linux (wslv2)` section in the Yocto Project Development
       Tasks Manual for more information.
 
 If you want more conceptual or background information on the Yocto
-Project, see the :doc:`../overview-manual/overview-manual`.
+Project, see the :doc:`/overview-manual/index`.
 
 Compatible Linux Distribution
 =============================
@@ -52,10 +52,10 @@
 -  Runs a supported Linux distribution (i.e. recent releases of Fedora,
    openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux
    distributions that support the Yocto Project, see the
-   :ref:`ref-manual/ref-system-requirements:supported linux distributions`
+   :ref:`ref-manual/system-requirements:supported linux distributions`
    section in the Yocto Project Reference Manual. For detailed
    information on preparing your build host, see the
-   :ref:`dev-manual/dev-manual-start:preparing the build host`
+   :ref:`dev-manual/start:preparing the build host`
    section in the Yocto Project Development Tasks Manual.
 
 -
@@ -68,7 +68,7 @@
 If your build host does not meet any of these three listed version
 requirements, you can take steps to prepare the system so that you
 can still use the Yocto Project. See the
-:ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`
+:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
 section in the Yocto Project Reference Manual for information.
 
 Build Host Packages
@@ -85,7 +85,7 @@
 .. note::
 
    For host package requirements on all supported Linux distributions,
-   see the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+   see the :ref:`ref-manual/system-requirements:required packages for the build host`
    section in the Yocto Project Reference Manual.
 
 Use Git to Clone Poky
@@ -145,7 +145,7 @@
 
 For more options and information about accessing Yocto Project related
 repositories, see the
-:ref:`dev-manual/dev-manual-start:locating yocto project source files`
+:ref:`dev-manual/start:locating yocto project source files`
 section in the Yocto Project Development Tasks Manual.
 
 Building Your Image
@@ -165,11 +165,11 @@
       infrastructure resources and get that information. A good starting
       point could also be to check your web browser settings. Finally,
       you can find more information on the
-      ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+      ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
       page of the Yocto Project Wiki.
 
 #. **Initialize the Build Environment:** From within the ``poky``
-   directory, run the :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``
+   directory, run the :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``
    environment
    setup script to define Yocto Project's build environment on your
    build host.
@@ -244,9 +244,9 @@
       $ bitbake core-image-sato
 
    For information on using the ``bitbake`` command, see the
-   :ref:`usingpoky-components-bitbake` section in the Yocto Project Overview and
+   :ref:`overview-manual/concepts:bitbake` section in the Yocto Project Overview and
    Concepts Manual, or see the ":ref:`BitBake Command
-   <bitbake:bitbake-user-manual-command>`" section in the BitBake User Manual.
+   <bitbake:bitbake-user-manual/bitbake-user-manual-intro:the bitbake command>`" section in the BitBake User Manual.
 
 #. **Simulate Your Image Using QEMU:** Once this particular image is
    built, you can start QEMU, which is a Quick EMUlator that ships with
@@ -257,7 +257,7 @@
       $ runqemu qemux86-64
 
    If you want to learn more about running QEMU, see the
-   :ref:`dev-manual/dev-manual-qemu:using the quick emulator (qemu)` chapter in
+   :ref:`dev-manual/qemu:using the quick emulator (qemu)` chapter in
    the Yocto Project Development Tasks Manual.
 
 #. **Exit QEMU:** Exit QEMU by either clicking on the shutdown icon or by typing
@@ -346,7 +346,7 @@
 
    You can find
    more information on adding layers in the
-   :ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`
+   :ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`
    section.
 
 Completing these steps has added the ``meta-altera`` layer to your Yocto
@@ -381,7 +381,7 @@
 
 For more information
 on layers and how to create them, see the
-:ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`
+:ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`
 section in the Yocto Project Development Tasks Manual.
 
 Where To Go Next
@@ -404,7 +404,7 @@
    concepts are useful for the beginner.
 
 -  **Yocto Project Overview and Concepts Manual:** The
-   :doc:`../overview-manual/overview-manual` is a great
+   :doc:`/overview-manual/index` is a great
    place to start to learn about the Yocto Project. This manual
    introduces you to the Yocto Project and its development environment.
    The manual also provides conceptual information for various aspects
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 4086202..068ab6c 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -44,7 +44,7 @@
 To help understand the BSP layer concept, consider the BSPs that the
 Yocto Project supports and provides with each release. You can see the
 layers in the
-:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+:ref:`overview-manual/development-environment:yocto project source repositories`
 through
 a web interface at :yocto_git:`/`. If you go to that interface,
 you will find a list of repositories under "Yocto Metadata Layers".
@@ -72,7 +72,7 @@
 section. For more
 information on how to set up a local copy of source files from a Git
 repository, see the
-:ref:`dev-manual/dev-manual-start:locating yocto project source files`
+:ref:`dev-manual/start:locating yocto project source files`
 section in the Yocto Project Development Tasks Manual.
 
 The BSP layer's base directory (``meta-bsp_root_name``) is the root
@@ -81,7 +81,7 @@
 ``conf/bblayers.conf`` file found in your
 :term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``).
+script (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
 layer and from it build an image. Here is an example: ::
@@ -128,7 +128,7 @@
 and so on.
 
 For more information on layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section of the Yocto Project Development Tasks Manual.
 
 Preparing Your Build Host to Work With BSP Layers
@@ -146,7 +146,7 @@
    :ref:`bsp-guide/bsp:example filesystem layout` section.
 
 #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
-   in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`"
+   in a shell. See the ":ref:`dev-manual/start:preparing the build host`"
    section in the Yocto Project Development Tasks Manual for information on how
    to get a build host ready that is either a native Linux machine or a machine
    that uses CROPS.
@@ -154,10 +154,10 @@
 #. *Clone the poky Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory` (i.e. a local
    ``poky`` repository). See the
-   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and
+   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
    possibly the
-   ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" or
-   ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
+   ":ref:`dev-manual/start:checking out by branch in poky`" or
+   ":ref:`dev-manual/start:checking out by tag in poky`"
    sections
    all in the Yocto Project Development Tasks Manual for information on
    how to clone the ``poky`` repository and check out the appropriate
@@ -172,8 +172,7 @@
 #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
    based on current Intel CPUs and devices, you can leverage this BSP
    layer. For details on the ``meta-intel`` BSP layer, see the layer's
-   `README <http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/README>`__
-   file.
+   :yocto_git:`README </meta-intel/tree/README>` file.
 
    #. *Navigate to Your Source Directory:* Typically, you set up the
       ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g.
@@ -206,7 +205,7 @@
 
          To see the available branch names in a cloned repository, use the ``git
          branch -al`` command. See the
-         ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`"
+         ":ref:`dev-manual/start:checking out by branch in poky`"
          section in the Yocto Project Development Tasks Manual for more
          information.
 
@@ -230,7 +229,7 @@
 
 #. *Initialize the Build Environment:* While in the root directory of
    the Source Directory (i.e. ``poky``), run the
-   :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\`` environment
+   :ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment
    setup script to define the OpenEmbedded build environment on your
    build host. ::
 
@@ -254,7 +253,7 @@
 OpenEmbedded build system. It is also intended that it will be be simple
 to extract information and convert it to other formats if required. The
 OpenEmbedded build system, through its standard :ref:`layers mechanism
-<overview-manual/overview-manual-yp-intro:the yocto project layer model>`, can
+<overview-manual/yp-intro:the yocto project layer model>`, can
 directly accept the format described as a layer. The BSP layer captures
 all the hardware-specific details in one place using a standard format,
 which is useful for any person wishing to use the hardware platform
@@ -464,7 +463,7 @@
 Licensing files can be MIT, BSD, GPLv*, and so forth. These files are
 recommended for the BSP but are optional and totally up to the BSP
 developer. For information on how to maintain license compliance, see
-the ":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+the ":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 README File
@@ -590,7 +589,7 @@
 
 These files define things such as the kernel package to use
 (:term:`PREFERRED_PROVIDER` of
-:ref:`virtual/kernel <dev-manual/dev-manual-common-tasks:using virtual providers>`),
+:ref:`virtual/kernel <dev-manual/common-tasks:using virtual providers>`),
 the hardware drivers to include in different types of images, any
 special software components that are needed, any bootloader information,
 and also any special image format requirements.
@@ -694,7 +693,7 @@
 particular BSP.
 
 You can find more information on what your append file should contain in
-the ":ref:`kernel-dev/kernel-dev-common:creating the append file`" section
+the ":ref:`kernel-dev/common:creating the append file`" section
 in the Yocto Project Linux Kernel Development Manual.
 
 An alternate scenario is when you create your own kernel recipe for the
@@ -727,7 +726,7 @@
    :align: center
 
 #. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":ref:`dev-manual/dev-manual-start:preparing the build host`"
+   Yocto Project*: See the ":ref:`dev-manual/start:preparing the build host`"
    section in the Yocto Project Development Tasks Manual for options on how to
    get a system ready to use the Yocto Project.
 
@@ -755,9 +754,9 @@
    are kept. The key point for a layer is that it is an isolated area
    that contains all the relevant information for the project that the
    OpenEmbedded build system knows about. For more information on
-   layers, see the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+   layers, see the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
    section in the Yocto Project Overview and Concepts Manual. You can also
-   reference the ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+   reference the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
    section in the Yocto Project Development Tasks Manual. For more
    information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`"
    section.
@@ -816,7 +815,7 @@
    key configuration files are configured appropriately: the
    ``conf/local.conf`` and the ``conf/bblayers.conf`` file. You must
    make the OpenEmbedded build system aware of your new layer. See the
-   ":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`"
+   ":ref:`dev-manual/common-tasks:enabling your layer`"
    section in the Yocto Project Development Tasks Manual for information
    on how to let the build system know about your new layer.
 
@@ -827,7 +826,7 @@
 
    The build process supports several types of images to satisfy
    different needs. See the
-   ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+   ":ref:`ref-manual/images:Images`" chapter in the Yocto
    Project Reference Manual for information on supported images.
 
 Requirements and Recommendations for Released BSPs
@@ -847,14 +846,14 @@
    layer that can be added to the Yocto Project. For guidelines on
    creating a layer that meets these base requirements, see the
    ":ref:`bsp-guide/bsp:bsp layers`" section in this manual and the
-   ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+   ":ref:`dev-manual/common-tasks:understanding and creating layers`"
    section in the Yocto Project Development Tasks Manual.
 
 -  The requirements in this section apply regardless of how you package
    a BSP. You should consult the packaging and distribution guidelines
    for your specific release process. For an example of packaging and
    distribution requirements, see the ":yocto_wiki:`Third Party BSP Release
-   Process </wiki/Third_Party_BSP_Release_Process>`"
+   Process </Third_Party_BSP_Release_Process>`"
    wiki page.
 
 -  The requirements for the BSP as it is made available to a developer
@@ -902,13 +901,13 @@
    ``meta-bsp_root_name`` directory. This license covers the BSP
    Metadata as a whole. You must specify which license to use since no
    default license exists when one is not specified. See the
-   :yocto_git:`COPYING.MIT </cgit.cgi/meta-raspberrypi/tree/COPYING.MIT>`
+   :yocto_git:`COPYING.MIT </meta-raspberrypi/tree/COPYING.MIT>`
    file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer
    as an example.
 
 -  *README File:* You must include a ``README`` file in the
    ``meta-bsp_root_name`` directory. See the
-   :yocto_git:`README.md </cgit.cgi/meta-raspberrypi/tree/README.md>`
+   :yocto_git:`README.md </meta-raspberrypi/tree/README.md>`
    file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer
    as an example.
 
@@ -929,7 +928,7 @@
    -  The name and contact information for the BSP layer maintainer.
       This is the person to whom patches and questions should be sent.
       For information on how to find the right person, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+      ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
       section in the Yocto Project Development Tasks Manual.
 
    -  Instructions on how to build the BSP using the BSP layer.
@@ -1014,7 +1013,7 @@
 the following:
 
 -  Create a ``*.bbappend`` file for the modified recipe. For information on using
-   append files, see the ":ref:`dev-manual/dev-manual-common-tasks:using
+   append files, see the ":ref:`dev-manual/common-tasks:using
    .bbappend files in your layer`" section in the Yocto Project Development
    Tasks Manual.
 
@@ -1119,7 +1118,7 @@
    Specifying the matching license string signifies that you agree to
    the license. Thus, the build system can build the corresponding
    recipe and include the component in the image. See the
-   ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+   ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
    section in the Yocto Project Development Tasks Manual for details on
    how to use these variables.
 
@@ -1171,7 +1170,7 @@
    ``create-layer`` subcommand to create a new general layer. For
    instructions on how to create a general layer using the
    ``bitbake-layers`` script, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Create a Layer Configuration File:* Every layer needs a layer
@@ -1181,16 +1180,16 @@
    :yocto_git:`Source Repositories <>`. To get examples of what you need
    in your configuration file, locate a layer (e.g. "meta-ti") and
    examine the
-   :yocto_git:`local.conf </cgit/cgit.cgi/meta-ti/tree/conf/layer.conf>`
+   :yocto_git:`local.conf </meta-ti/tree/conf/layer.conf>`
    file.
 
 -  *Create a Machine Configuration File:* Create a
    ``conf/machine/bsp_root_name.conf`` file. See
-   :yocto_git:`meta-yocto-bsp/conf/machine </cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine>`
+   :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>`
    for sample ``bsp_root_name.conf`` files. Other samples such as
-   :yocto_git:`meta-ti </cgit/cgit.cgi/meta-ti/tree/conf/machine>`
+   :yocto_git:`meta-ti </meta-ti/tree/conf/machine>`
    and
-   :yocto_git:`meta-freescale </cgit/cgit.cgi/meta-freescale/tree/conf/machine>`
+   :yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>`
    exist from other vendors that have more specific machine and tuning
    examples.
 
@@ -1198,13 +1197,13 @@
    ``recipes-kernel/linux`` by either using a kernel append file or a
    new custom kernel recipe file (e.g. ``yocto-linux_4.12.bb``). The BSP
    layers mentioned in the previous step also contain different kernel
-   examples. See the ":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`"
+   examples. See the ":ref:`kernel-dev/common:modifying an existing recipe`"
    section in the Yocto Project Linux Kernel Development Manual for
    information on how to create a custom kernel.
 
 The remainder of this section provides a description of the Yocto
 Project reference BSP for Beaglebone, which resides in the
-:yocto_git:`meta-yocto-bsp </cgit/cgit.cgi/poky/tree/meta-yocto-bsp>`
+:yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
 layer.
 
 BSP Layer Configuration Example
@@ -1231,7 +1230,7 @@
 :yocto_git:`Source Repositories <>`.
 
 For a detailed description of this particular layer configuration file,
-see ":ref:`step 3 <dev-manual/dev-manual-common-tasks:creating your own layer>`"
+see ":ref:`step 3 <dev-manual/common-tasks:creating your own layer>`"
 in the discussion that describes how to create layers in the Yocto
 Project Development Tasks Manual.
 
@@ -1306,7 +1305,7 @@
 development boards. Realize that much more can be defined as part of a
 machine's configuration file. In general, you can learn about related
 variables that this example does not have by locating the variables in
-the ":ref:`ref-manual/ref-variables:variables glossary`" in the Yocto
+the ":ref:`ref-manual/variables:variables glossary`" in the Yocto
 Project Reference Manual.
 
 -  :term:`PREFERRED_PROVIDER_virtual/xserver <PREFERRED_PROVIDER>`:
@@ -1361,7 +1360,7 @@
    `JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image.
 
 -  :term:`WKS_FILE`: The location of
-   the :ref:`Wic kickstart <ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used
+   the :ref:`Wic kickstart <ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used
    by the OpenEmbedded build system to create a partitioned image
    (image.wic).
 
@@ -1413,7 +1412,7 @@
    .. note::
 
       For more information on how the SPL variables are used, see the
-      :yocto_git:`u-boot.inc </cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc>`
+      :yocto_git:`u-boot.inc </poky/tree/meta/recipes-bsp/u-boot/u-boot.inc>`
       include file.
 
 -  :term:`UBOOT_* <UBOOT_ENTRYPOINT>`: Defines
@@ -1457,7 +1456,7 @@
 metadata used to build the kernel. In this case, a kernel append file
 (i.e. ``linux-yocto_5.0.bbappend``) is used to override an established
 kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in
-:yocto_git:`/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux`.
+:yocto_git:`/poky/tree/meta/recipes-kernel/linux`.
 
 Following is the contents of the append file: ::
 
diff --git a/poky/documentation/bsp-guide/bsp-guide.rst b/poky/documentation/bsp-guide/index.rst
similarity index 100%
rename from poky/documentation/bsp-guide/bsp-guide.rst
rename to poky/documentation/bsp-guide/index.rst
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index 96118ab..a626b1f 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -69,13 +69,13 @@
 # external links and substitutions
 extlinks = {
     'yocto_home': ('https://yoctoproject.org%s', None),
-    'yocto_wiki': ('https://wiki.yoctoproject.org%s', None),
+    'yocto_wiki': ('https://wiki.yoctoproject.org/wiki%s', None),
     'yocto_dl': ('https://downloads.yoctoproject.org%s', None),
     'yocto_lists': ('https://lists.yoctoproject.org%s', None),
     'yocto_bugs': ('https://bugzilla.yoctoproject.org%s', None),
     'yocto_ab': ('https://autobuilder.yoctoproject.org%s', None),
     'yocto_docs': ('https://docs.yoctoproject.org%s', None),
-    'yocto_git': ('https://git.yoctoproject.org%s', None),
+    'yocto_git': ('https://git.yoctoproject.org/cgit/cgit.cgi%s', None),
     'oe_home': ('https://www.openembedded.org%s', None),
     'oe_lists': ('https://lists.openembedded.org%s', None),
     'oe_git': ('https://git.openembedded.org%s', None),
diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
similarity index 97%
rename from poky/documentation/dev-manual/dev-manual-common-tasks.rst
rename to poky/documentation/dev-manual/common-tasks.rst
index 683f555..ada3bac 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -18,7 +18,7 @@
 Layers allow you to isolate different types of customizations from each
 other. For introductory information on the Yocto Project Layer Model,
 see the
-":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+":ref:`overview-manual/yp-intro:the yocto project layer model`"
 section in the Yocto Project Overview and Concepts Manual.
 
 Creating Your Own Layer
@@ -31,7 +31,7 @@
 layer-creation tools, see the
 ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
 section in the Yocto Project Board Support Package (BSP) Developer's
-Guide and the ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+Guide and the ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
 section further down in this manual.
 
 Follow these general steps to create your layer without using tools:
@@ -75,7 +75,7 @@
    ``conf`` directory and then modify the file as needed.
 
    The ``meta-yocto-bsp/conf/layer.conf`` file in the Yocto Project
-   :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf>`
+   :yocto_git:`Source Repositories </poky/tree/meta-yocto-bsp/conf>`
    demonstrates the required syntax. For your layer, you need to replace
    "yoctobsp" with a unique identifier for your layer (e.g. "machinexyz"
    for a layer named "meta-machinexyz"):
@@ -135,7 +135,7 @@
       Lists all layers on which this layer depends (if any).
 
    -  :term:`LAYERSERIES_COMPAT`:
-      Lists the :yocto_wiki:`Yocto Project </wiki/Releases>`
+      Lists the :yocto_wiki:`Yocto Project </Releases>`
       releases for which the current version is compatible. This
       variable is a good way to indicate if your particular layer is
       current.
@@ -160,8 +160,6 @@
    Project <#making-sure-your-layer-is-compatible-with-yocto-project>`__"
    section for more information.
 
-.. _best-practices-to-follow-when-creating-layers:
-
 Following Best Practices When Creating Layers
 ---------------------------------------------
 
@@ -457,8 +455,6 @@
 adds the recipes, classes and configurations contained within the
 particular layer to the source directory.
 
-.. _using-bbappend-files:
-
 Using .bbappend Files in Your Layer
 -----------------------------------
 
@@ -729,7 +725,7 @@
 
    -  In order to use a layer with the OpenEmbedded build system, you
       need to add the layer to your ``bblayers.conf`` configuration
-      file. See the ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+      file. See the ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
       section for more information.
 
 The default mode of the script's operation with this subcommand is to
@@ -839,16 +835,12 @@
    During a build, the OpenEmbedded build system looks in the layers
    from the top of the list down to the bottom in that order.
 
-.. _usingpoky-extend-customimage:
-
 Customizing Images
 ==================
 
 You can customize images to satisfy particular requirements. This
 section describes several methods and provides guidelines for each.
 
-.. _usingpoky-extend-customimage-localconf:
-
 Customizing Images Using ``local.conf``
 ---------------------------------------
 
@@ -891,8 +883,6 @@
 ``CORE_IMAGE_EXTRA_INSTALL`` variable. If you use this variable, only
 ``core-image-*`` images are affected.
 
-.. _usingpoky-extend-customimage-imagefeatures:
-
 Customizing Images Using Custom ``IMAGE_FEATURES`` and ``EXTRA_IMAGE_FEATURES``
 -------------------------------------------------------------------------------
 
@@ -945,12 +935,10 @@
 
 .. note::
 
-   See the ":ref:`ref-manual/ref-features:image features`" section in the Yocto
+   See the ":ref:`ref-manual/features:image features`" section in the Yocto
    Project Reference Manual for a complete list of image features that ship
    with the Yocto Project.
 
-.. _usingpoky-extend-customimage-custombb:
-
 Customizing Images Using Custom .bb Files
 -----------------------------------------
 
@@ -977,8 +965,6 @@
 
    IMAGE_INSTALL += "strace"
 
-.. _usingpoky-extend-customimage-customtasks:
-
 Customizing Images Using Custom Package Groups
 ----------------------------------------------
 
@@ -1039,8 +1025,6 @@
 ``IMAGE_INSTALL``. For other forms of image dependencies see the other
 areas of this section.
 
-.. _usingpoky-extend-customimage-image-name:
-
 Customizing an Image Hostname
 -----------------------------
 
@@ -1080,8 +1064,6 @@
 Having no default hostname in the filesystem is suitable for
 environments that use dynamic hostnames such as virtual machines.
 
-.. _new-recipe-writing-a-new-recipe:
-
 Writing a New Recipe
 ====================
 
@@ -1094,11 +1076,9 @@
 
    For information on variables that are useful for recipes and for
    information about recipe naming issues, see the
-   ":ref:`ref-manual/ref-varlocality:recipes`" section of the Yocto Project
+   ":ref:`ref-manual/varlocality:recipes`" section of the Yocto Project
    Reference Manual.
 
-.. _new-recipe-overview:
-
 Overview
 --------
 
@@ -1108,8 +1088,6 @@
 .. image:: figures/recipe-workflow.png
    :align: center
 
-.. _new-recipe-locate-or-automatically-create-a-base-recipe:
-
 Locate or Automatically Create a Base Recipe
 --------------------------------------------
 
@@ -1128,9 +1106,7 @@
 .. note::
 
    For information on recipe syntax, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:recipe syntax`" section.
-
-.. _new-recipe-creating-the-base-recipe-using-devtool:
+   ":ref:`dev-manual/common-tasks:recipe syntax`" section.
 
 Creating the Base Recipe Using ``devtool add``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1143,12 +1119,10 @@
 included in a build.
 
 You can find a complete description of the ``devtool add`` command in
-the ":ref:`sdk-manual/sdk-extensible:a closer look at \`\`devtool add\`\``" section
+the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
 in the Yocto Project Application Development and the Extensible Software
 Development Kit (eSDK) manual.
 
-.. _new-recipe-creating-the-base-recipe-using-recipetool:
-
 Creating the Base Recipe Using ``recipetool create``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1213,8 +1187,6 @@
 
       recipetool create -d -o OUTFILE source
 
-.. _new-recipe-locating-and-using-a-similar-recipe:
-
 Locating and Using a Similar Recipe
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1254,8 +1226,6 @@
 
       SRC_URI = ""
 
-.. _new-recipe-storing-and-naming-the-recipe:
-
 Storing and Naming the Recipe
 -----------------------------
 
@@ -1298,8 +1268,6 @@
       gawk_4.0.2.bb
       irssi_0.8.16-rc1.bb
 
-.. _new-recipe-running-a-build-on-the-recipe:
-
 Running a Build on the Recipe
 -----------------------------
 
@@ -1351,11 +1319,9 @@
    ``log.do_fetch``, and ``log.do_compile``).
 
 You can find more information about the build process in
-":doc:`../overview-manual/overview-manual-development-environment`"
+":doc:`/overview-manual/development-environment`"
 chapter of the Yocto Project Overview and Concepts Manual.
 
-.. _new-recipe-fetching-code:
-
 Fetching Code
 -------------
 
@@ -1364,12 +1330,12 @@
 :term:`SRC_URI` variable. Your recipe
 must have a ``SRC_URI`` variable that points to where the source is
 located. For a graphical representation of source locations, see the
-":ref:`sources-dev-environment`" section in
+":ref:`overview-manual/concepts:sources`" section in
 the Yocto Project Overview and Concepts Manual.
 
 The :ref:`ref-tasks-fetch` task uses
 the prefix of each entry in the ``SRC_URI`` variable value to determine
-which :ref:`fetcher <bitbake:bb-fetchers>` to use to get your
+which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to get your
 source files. It is the ``SRC_URI`` variable that triggers the fetcher.
 The :ref:`ref-tasks-patch` task uses
 the variable after source is fetched to apply patches. The OpenEmbedded
@@ -1490,8 +1456,6 @@
 The build system automatically applies patches as described in the
 "`Patching Code <#new-recipe-patching-code>`__" section.
 
-.. _new-recipe-unpacking-code:
-
 Unpacking Code
 --------------
 
@@ -1512,8 +1476,6 @@
 files, you need to be sure that the directory pointed to by ``${S}``
 matches the structure of the source.
 
-.. _new-recipe-patching-code:
-
 Patching Code
 -------------
 
@@ -1539,8 +1501,6 @@
 (:term:`BP` and
 :term:`BPN`) or "files".
 
-.. _new-recipe-licensing:
-
 Licensing
 ---------
 
@@ -1578,7 +1538,7 @@
    differences result in an error with the message containing the
    current checksum. For more explanation and examples of how to set the
    ``LIC_FILES_CHKSUM`` variable, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section.
+   ":ref:`dev-manual/common-tasks:tracking license changes`" section.
 
    To determine the correct checksum string, you can list the
    appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect
@@ -1597,8 +1557,6 @@
    correct string that you can substitute into the recipe file for a
    subsequent build.
 
-.. _new-dependencies:
-
 Dependencies
 ------------
 
@@ -1641,12 +1599,10 @@
 contains a binary that links to "libexample" then the OpenEmbedded build
 system will automatically add a runtime dependency to "mypackage" on
 "example"). See the
-":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+":ref:`overview-manual/concepts:automatically added runtime dependencies`"
 section in the Yocto Project Overview and Concepts Manual for further
 details.
 
-.. _new-recipe-configuring-the-recipe:
-
 Configuring the Recipe
 ----------------------
 
@@ -1741,8 +1697,6 @@
 ``./configure --help`` command within ``${S}`` or consult the software's
 upstream documentation.
 
-.. _new-recipe-using-headers-to-interface-with-devices:
-
 Using Headers to Interface with Devices
 ---------------------------------------
 
@@ -1802,8 +1756,6 @@
 
    do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
-.. _new-recipe-compilation:
-
 Compilation
 -----------
 
@@ -1819,7 +1771,7 @@
    For cases where improper paths are detected for configuration files
    or for when libraries/headers cannot be found, be sure you are using
    the more robust ``pkg-config``. See the note in section
-   ":ref:`dev-manual/dev-manual-common-tasks:Configuring the Recipe`" for additional information.
+   ":ref:`dev-manual/common-tasks:Configuring the Recipe`" for additional information.
 
 -  *Parallel build failures:* These failures manifest themselves as
    intermittent errors, or errors reporting that a file or directory
@@ -1867,8 +1819,6 @@
    ``STAGING_BINDIR``, ``STAGING_INCDIR``, ``STAGING_DATADIR``, and so
    forth).
 
-.. _new-recipe-installing:
-
 Installing
 ----------
 
@@ -1956,8 +1906,6 @@
       files to ``${D}${datadir}/cmake/Modules`` during
       :ref:`ref-tasks-install`.
 
-.. _new-recipe-enabling-system-services:
-
 Enabling System Services
 ------------------------
 
@@ -2009,8 +1957,6 @@
    section for
    more information.
 
-.. _new-recipe-packaging:
-
 Packaging
 ---------
 
@@ -2032,7 +1978,7 @@
    of common problems that show up during runtime. For information on
    these checks, see the
    :ref:`insane <ref-classes-insane>` class and
-   the ":ref:`ref-manual/ref-qa-checks:qa error and warning messages`"
+   the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
    chapter in the Yocto Project Reference Manual.
 
 -  *Hand-Checking Your Packages*: After you build your software, you
@@ -2089,8 +2035,6 @@
    target machine, particularly if you run separate builds for more than
    one target machine.
 
-.. _new-sharing-files-between-recipes:
-
 Sharing Files Between Recipes
 -----------------------------
 
@@ -2137,8 +2081,6 @@
 task and its associated functions, see the
 :ref:`staging <ref-classes-staging>` class.
 
-.. _metadata-virtual-providers:
-
 Using Virtual Providers
 -----------------------
 
@@ -2165,15 +2107,12 @@
 
 Now comes the time to actually build an image and you need a kernel
 recipe, but which one? You can configure your build to call out the
-kernel recipe you want by using the
-:term:`PREFERRED_PROVIDER`
-variable. As an example, consider the
-`x86-base.inc <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/x86-base.inc>`_
-include file, which is a machine (i.e.
-:term:`MACHINE`) configuration file.
-This include file is the reason all x86-based machines use the
-``linux-yocto`` kernel. Here are the relevant lines from the include
-file:
+kernel recipe you want by using the :term:`PREFERRED_PROVIDER` variable. As
+an example, consider the :yocto_git:`x86-base.inc
+</poky/tree/meta/conf/machine/include/x86-base.inc>` include file, which is a
+machine (i.e. :term:`MACHINE`) configuration file. This include file is the
+reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
+relevant lines from the include file:
 ::
 
    PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
@@ -2251,8 +2190,6 @@
    REALPV = "0.8.16-rc1"
    PV = "0.8.15+${REALPV}"
 
-.. _new-recipe-post-installation-scripts:
-
 Post-Installation Scripts
 -------------------------
 
@@ -2313,8 +2250,6 @@
    because of when they run, they are not applicable to being run at image
    creation time like ``pkg_postinst``.
 
-.. _new-recipe-testing:
-
 Testing
 -------
 
@@ -2326,8 +2261,6 @@
 packages, see the "`Customizing
 Images <#usingpoky-extend-customimage>`__" section.
 
-.. _new-recipe-testing-examples:
-
 Examples
 --------
 
@@ -2344,8 +2277,6 @@
 
 -  Adding binaries to an image
 
-.. _new-recipe-single-c-file-package-hello-world:
-
 Single .c File Package (Hello World!)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2382,8 +2313,6 @@
 Multiple Packages <#splitting-an-application-into-multiple-packages>`__"
 section.
 
-.. _new-recipe-autotooled-package:
-
 Autotooled Package
 ~~~~~~~~~~~~~~~~~~
 
@@ -2409,12 +2338,10 @@
 
 The variable ``LIC_FILES_CHKSUM`` is used to track source license
 changes as described in the
-":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section in
+":ref:`dev-manual/common-tasks:tracking license changes`" section in
 the Yocto Project Overview and Concepts Manual. You can quickly create
 Autotool-based recipes in a manner similar to the previous example.
 
-.. _new-recipe-makefile-based-package:
-
 Makefile-Based Package
 ~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2559,7 +2486,7 @@
 
    -  Using ``DEPENDS`` also allows runtime dependencies between
       packages to be added automatically. See the
-      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+      ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual for more
       information.
 
@@ -2864,8 +2791,6 @@
    might wish to use. If in doubt, you should check with multiple
    implementations - including those from BusyBox.
 
-.. _platdev-newmachine:
-
 Adding a New Machine
 ====================
 
@@ -2885,8 +2810,6 @@
 section in the Yocto Project Board Support Package (BSP) Developer's
 Guide.
 
-.. _platdev-newmachine-conffile:
-
 Adding the Machine Configuration File
 -------------------------------------
 
@@ -2920,8 +2843,6 @@
 You can leverage existing machine ``.conf`` files from
 ``meta-yocto-bsp/conf/machine/``.
 
-.. _platdev-newmachine-kernel:
-
 Adding a Kernel for the Machine
 -------------------------------
 
@@ -2953,11 +2874,9 @@
    COMPATIBLE_MACHINE = '(qemux86|qemumips)'
 
 For more information on ``defconfig`` files, see the
-":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
+":ref:`kernel-dev/common:changing the configuration`"
 section in the Yocto Project Linux Kernel Development Manual.
 
-.. _platdev-newmachine-formfactor:
-
 Adding a Formfactor Configuration File
 --------------------------------------
 
@@ -2990,8 +2909,6 @@
    DISPLAY_DPI=150
    DISPLAY_SUBPIXEL_ORDER=vrgb
 
-.. _gs-upgrading-recipes:
-
 Upgrading Recipes
 =================
 
@@ -3011,8 +2928,6 @@
 ``devtool upgrade`` to set up semi-automatic version upgrades. Finally,
 you can manually upgrade a recipe by editing the recipe itself.
 
-.. _gs-using-the-auto-upgrade-helper:
-
 Using the Auto Upgrade Helper (AUH)
 -----------------------------------
 
@@ -3048,7 +2963,7 @@
 1. *Be Sure the Development Host is Set Up:* You need to be sure that
    your development host is set up to use the Yocto Project. For
    information on how to set up your host, see the
-   ":ref:`dev-manual/dev-manual-start:Preparing the Build Host`" section.
+   ":ref:`dev-manual/start:Preparing the Build Host`" section.
 
 2. *Make Sure Git is Configured:* The AUH utility requires Git to be
    configured because AUH uses Git to save upgrades. Thus, you must have
@@ -3100,7 +3015,7 @@
    configurations:
 
    -  If you want to enable :ref:`Build
-      History <dev-manual/dev-manual-common-tasks:maintaining build output quality>`,
+      History <dev-manual/common-tasks:maintaining build output quality>`,
       which is optional, you need the following lines in the
       ``conf/local.conf`` file:
       ::
@@ -3140,7 +3055,7 @@
 7. *Create and Edit an AUH Configuration File:* You need to have the
    ``upgrade-helper/upgrade-helper.conf`` configuration file in your
    build directory. You can find a sample configuration file in the
-   :yocto_git:`AUH source repository </cgit/cgit.cgi/auto-upgrade-helper/tree/>`.
+   :yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`.
 
    Read through the sample file and make configurations as needed. For
    example, if you enabled build history in your ``local.conf`` as
@@ -3204,19 +3119,17 @@
 
 You can easily set up to run the AUH utility on a regular basis by using
 a cron job. See the
-:yocto_git:`weeklyjob.sh </cgit/cgit.cgi/auto-upgrade-helper/tree/weeklyjob.sh>`
+:yocto_git:`weeklyjob.sh </auto-upgrade-helper/tree/weeklyjob.sh>`
 file distributed with the utility for an example.
 
-.. _gs-using-devtool-upgrade:
-
 Using ``devtool upgrade``
 -------------------------
 
 As mentioned earlier, an alternative method for upgrading recipes to
 newer versions is to use
-:doc:`devtool upgrade <../ref-manual/ref-devtool-reference>`.
+:doc:`devtool upgrade </ref-manual/devtool-reference>`.
 You can read about ``devtool upgrade`` in general in the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
+":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) Manual.
 
@@ -3350,14 +3263,12 @@
 file based on your commits. The tool puts all patch files back into the
 source directory in a sub-directory named ``nano`` in this case.
 
-.. _dev-manually-upgrading-a-recipe:
-
 Manually Upgrading a Recipe
 ---------------------------
 
 If for some reason you choose not to upgrade recipes using
-:ref:`dev-manual/dev-manual-common-tasks:Using the Auto Upgrade Helper (AUH)` or
-by :ref:`dev-manual/dev-manual-common-tasks:Using \`\`devtool upgrade\`\``,
+:ref:`dev-manual/common-tasks:Using the Auto Upgrade Helper (AUH)` or
+by :ref:`dev-manual/common-tasks:Using \`\`devtool upgrade\`\``,
 you can manually edit the recipe files to upgrade the versions.
 
 .. note::
@@ -3419,8 +3330,6 @@
    builds work and any testing is successful, you can create commits for
    any changes in the layer holding your upgraded recipe.
 
-.. _finding-the-temporary-source-code:
-
 Finding Temporary Source Code
 =============================
 
@@ -3491,8 +3400,6 @@
 
    poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
 
-.. _using-a-quilt-workflow:
-
 Using Quilt in Your Workflow
 ============================
 
@@ -3506,7 +3413,7 @@
 
    With regard to preserving changes to source files, if you clean a
    recipe or have ``rm_work`` enabled, the
-   :ref:`devtool workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+   :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
    as described in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual is a safer
    development flow than the flow that uses Quilt.
@@ -3560,7 +3467,7 @@
       (i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
       Modifications will also disappear if you use the ``rm_work`` feature as
       described in the
-      ":ref:`dev-manual/dev-manual-common-tasks:conserving disk space during builds`"
+      ":ref:`dev-manual/common-tasks:conserving disk space during builds`"
       section.
 
 7. *Generate the Patch:* Once your changes work as expected, you need to
@@ -3587,8 +3494,6 @@
 
       SRC_URI += "file://my_changes.patch"
 
-.. _platdev-appdev-devshell:
-
 Using a Development Shell
 =========================
 
@@ -3671,8 +3576,6 @@
    -  It is also worth noting that ``devshell`` still works over X11
       forwarding and similar situations.
 
-.. _platdev-appdev-devpyshell:
-
 Using a Development Python Shell
 ================================
 
@@ -3720,8 +3623,6 @@
 When you are finished using ``devpyshell``, you can exit the shell
 either by using Ctrl+d or closing the terminal window.
 
-.. _dev-building:
-
 Building
 ========
 
@@ -3729,8 +3630,6 @@
 needed for a simple build, a target that uses multiple configurations,
 building an image for more than one machine, and so forth.
 
-.. _dev-building-a-simple-image:
-
 Building a Simple Image
 -----------------------
 
@@ -3745,21 +3644,21 @@
 
    -  For information on how to build an image using
       :term:`Toaster`, see the
-      :doc:`../toaster-manual/toaster-manual`.
+      :doc:`/toaster-manual/index`.
 
    -  For information on how to use ``devtool`` to build images, see the
-      ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+      ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
    -  For a quick example on how to build an image using the
       OpenEmbedded build system, see the
-      :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+      :doc:`/brief-yoctoprojectqs/index` document.
 
 The build process creates an entire Linux distribution from source and
 places it in your :term:`Build Directory` under
 ``tmp/deploy/images``. For detailed information on the build process
-using BitBake, see the ":ref:`images-dev-environment`" section in the
+using BitBake, see the ":ref:`overview-manual/concepts:images`" section in the
 Yocto Project Overview and Concepts Manual.
 
 The following figure and list overviews the build process:
@@ -3768,7 +3667,7 @@
    :align: center
 
 1. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":doc:`dev-manual-start`" section for options on how to get a
+   Yocto Project*: See the ":doc:`start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
 2. *Initialize the Build Environment:* Initialize the build environment
@@ -3815,7 +3714,7 @@
    can be the name of a recipe for a specific piece of software such as
    BusyBox. For more details about the images the OpenEmbedded build
    system supports, see the
-   ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+   ":ref:`ref-manual/images:Images`" chapter in the Yocto
    Project Reference Manual.
 
    As an example, the following command builds the
@@ -3829,12 +3728,10 @@
    kernels built by the OpenEmbedded build system are placed in the
    Build Directory in ``tmp/deploy/images``. For information on how to
    run pre-built images such as ``qemux86`` and ``qemuarm``, see the
-   :doc:`../sdk-manual/sdk-manual` manual. For
+   :doc:`/sdk-manual/index` manual. For
    information about how to install these images, see the documentation
    for your particular board or machine.
 
-.. _dev-building-images-for-multiple-targets-using-multiple-configurations:
-
 Building Images for Multiple Targets Using Multiple Configurations
 ------------------------------------------------------------------
 
@@ -3848,8 +3745,6 @@
 and how to account for cross-build dependencies between the
 multiconfigs.
 
-.. _dev-setting-up-and-running-a-multiple-configuration-build:
-
 Setting Up and Running a Multiple Configuration Build
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -3942,8 +3837,6 @@
    directories, the build either loads from an existing sstate cache for
    that build at the start or builds the object fresh.
 
-.. _dev-enabling-multiple-configuration-build-dependencies:
-
 Enabling Multiple Configuration Build Dependencies
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -4003,8 +3896,6 @@
 each build in the respective temporary build directories (i.e.
 :term:`TMPDIR`).
 
-.. _building-an-initramfs-image:
-
 Building an Initial RAM Filesystem (initramfs) Image
 ----------------------------------------------------
 
@@ -4095,8 +3986,6 @@
 which is around 5 Mbytes, that can be built out-of-the-box using the
 Yocto Project.
 
-.. _tiny-system-overview:
-
 Tiny System Overview
 ~~~~~~~~~~~~~~~~~~~~
 
@@ -4145,8 +4034,6 @@
    information on how to create layers, see the "`Understanding and
    Creating Layers <#understanding-and-creating-layers>`__" section.
 
-.. _understand-what-gives-your-image-size:
-
 Understand What Contributes to Your Image Size
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -4159,7 +4046,7 @@
 
    To use ``poky-tiny`` in your build, set the ``DISTRO`` variable in your
    ``local.conf`` file to "poky-tiny" as described in the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating your own distribution`"
+   ":ref:`dev-manual/common-tasks:creating your own distribution`"
    section.
 
 Understanding some memory concepts will help you reduce the system size.
@@ -4197,7 +4084,7 @@
    directory.
 
    For more information on configuration fragments, see the
-   ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+   ":ref:`kernel-dev/common:creating configuration fragments`"
    section in the Yocto Project Linux Kernel Development Manual.
 
 -  ``bitbake -u taskexp -g bitbake_target``: Using the BitBake command
@@ -4472,9 +4359,9 @@
    higher levels noted earlier can be useful. For example, consider how
    NXP (formerly Freescale) allows for the easy reuse of binary packages
    in their layer
-   :yocto_git:`meta-freescale </cgit/cgit.cgi/meta-freescale/>`.
+   :yocto_git:`meta-freescale </meta-freescale/>`.
    In this example, the
-   :yocto_git:`fsl-dynamic-packagearch </cgit/cgit.cgi/meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
+   :yocto_git:`fsl-dynamic-packagearch </meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
    class shares GPU packages for i.MX53 boards because all boards share
    the AMD GPU. The i.MX6-based boards can do the same because all
    boards share the Vivante GPU. This class inspects the BitBake
@@ -4812,8 +4699,6 @@
          the static libraries. If so, you might need to exclude them as
          well.
 
-.. _platdev-working-with-libraries:
-
 Working With Libraries
 ======================
 
@@ -4889,8 +4774,6 @@
    SECTION_${PN}-staticdev = "devel"
    RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
 
-.. _combining-multiple-versions-library-files-into-one-image:
-
 Combining Multiple Versions of Library Files into One Image
 -----------------------------------------------------------
 
@@ -5299,8 +5182,6 @@
    under 32-bit host machines. In particular, "qemumips64" is known to
    not work under i686.
 
-.. _dev-optionally-using-an-external-toolchain:
-
 Optionally Using an External Toolchain
 ======================================
 
@@ -5353,7 +5234,7 @@
 .. note::
 
    For a kickstart file reference, see the
-   ":ref:`ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
+   ":ref:`ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
    Chapter in the Yocto Project Reference Manual.
 
 The ``wic`` command and the infrastructure it is based on is by
@@ -5368,8 +5249,6 @@
 to use the Wic utility, provides information on using the Wic plugins
 interface, and provides several examples that show how to use Wic.
 
-.. _wic-background:
-
 Background
 ----------
 
@@ -5395,8 +5274,6 @@
    general-purpose partitioning language, which is based on Redhat
    kickstart syntax.
 
-.. _wic-requirements:
-
 Requirements
 ------------
 
@@ -5435,8 +5312,6 @@
 -  Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>`
    as part of the :term:`WKS_FILE` variable
 
-.. _wic-getting-help:
-
 Getting Help
 ------------
 
@@ -5610,14 +5485,12 @@
                                 name of the image to use the artifacts from e.g. core-
                                 image-sato
 
-.. _using-a-provided-kickstart-file:
-
 Using an Existing Kickstart File
 --------------------------------
 
 If you do not want to create your own kickstart file, you can use an
 existing file provided by the Wic installation. As shipped, kickstart
-files can be found in the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in the
+files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
 following two locations:
 ::
 
@@ -5661,8 +5534,6 @@
 
    bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"
 
-.. _wic-using-the-wic-plugin-interface:
-
 Using the Wic Plugin Interface
 ------------------------------
 
@@ -5690,7 +5561,7 @@
 Source plugins are subclasses defined in plugin files. As shipped, the
 Yocto Project provides several plugin files. You can see the source
 plugin files that ship with the Yocto Project
-:yocto_git:`here </cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source>`.
+:yocto_git:`here </poky/tree/scripts/lib/wic/plugins/source>`.
 Each of these plugin files contains source plugins that are designed to
 populate a specific Wic image partition.
 
@@ -5802,8 +5673,6 @@
 interest. On success, these will be filled in with the actual methods.
 See the Wic implementation for examples and details.
 
-.. _wic-usage-examples:
-
 Wic Examples
 ------------
 
@@ -5813,8 +5682,6 @@
 examples assume the previously generated image is
 ``core-image-minimal``.
 
-.. _generate-an-image-using-a-provided-kickstart-file:
-
 Generate an Image using an Existing Kickstart File
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -5869,7 +5736,7 @@
 
    For more information on how to use the ``bmaptool``
    to flash a device with an image, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\``"
+   ":ref:`dev-manual/common-tasks:flashing images using \`\`bmaptool\`\``"
    section.
 
 Using a Modified Kickstart File
@@ -6089,7 +5956,7 @@
 
    Once the new kernel is added back into the image, you can use the
    ``dd`` command or :ref:`bmaptool
-   <dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\`>`
+   <dev-manual/common-tasks:flashing images using \`\`bmaptool\`\`>`
    to flash your wic image onto an SD card or USB stick and test your
    target.
 
@@ -6305,7 +6172,7 @@
 -  Consider enabling a Mandatory Access Control (MAC) framework such as
    SMACK or SELinux and tuning it appropriately for your device's usage.
    You can find more information in the
-   :yocto_git:`meta-selinux </cgit/cgit.cgi/meta-selinux/>` layer.
+   :yocto_git:`meta-selinux </meta-selinux/>` layer.
 
 Tools for Hardening Your Image
 ------------------------------
@@ -6335,7 +6202,7 @@
    just placing configurations in a ``local.conf`` configuration file
    makes it easier to reproduce the same build configuration when using
    multiple build machines. See the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
    section for information on how to quickly set up a layer.
 
 -  *Create the distribution configuration file:* The distribution
@@ -6495,8 +6362,6 @@
 ``conf-notes.txt`` in your custom template configuration directory and
 making sure you have ``TEMPLATECONF`` set to your directory.
 
-.. _dev-saving-memory-during-a-build:
-
 Conserving Disk Space During Builds
 ===================================
 
@@ -6573,8 +6438,6 @@
    prevent the installation of a package whose presence is required by
    an installed package.
 
-.. _incrementing-a-binary-package-version:
-
 Incrementing a Package Version
 ------------------------------
 
@@ -6610,7 +6473,7 @@
    build system uses this string to help define the value of ``PV`` when
    the source code revision needs to be included in it.
 
--  :yocto_wiki:`PR Service </wiki/PR_Service>`: A
+-  :yocto_wiki:`PR Service </PR_Service>`: A
    network-based service that helps automate keeping package feeds
    compatible with existing package manager applications such as RPM,
    APT, and OPKG.
@@ -6652,7 +6515,7 @@
 .. note::
 
    For additional information on using a PR Service, you can see the
-   :yocto_wiki:`PR Service </wiki/PR_Service>` wiki page.
+   :yocto_wiki:`PR Service </PR_Service>` wiki page.
 
 The Yocto Project uses variables in order of decreasing priority to
 facilitate revision numbering (i.e.
@@ -6663,7 +6526,7 @@
 and procedures of a given distribution and package feed.
 
 Because the OpenEmbedded build system uses
-":ref:`signatures <overview-checksums>`", which are
+":ref:`signatures <overview-manual/concepts:checksums (signatures)>`", which are
 unique to a given build, the build system knows when to rebuild
 packages. All the inputs into a given task are represented by a
 signature, which can trigger a rebuild when different. Thus, the build
@@ -6737,7 +6600,7 @@
    use a PR Service while others do not leads to obvious problems.
 
    For more information on shared state, see the
-   ":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+   ":ref:`overview-manual/concepts:shared state cache`"
    section in the Yocto Project Overview and Concepts Manual.
 
 Manually Bumping PR
@@ -6777,8 +6640,6 @@
 These guidelines define how versions are compared and what "increasing"
 a version means.
 
-.. _automatically-incrementing-a-binary-package-revision-number:
-
 Automatically Incrementing a Package Version Number
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -6906,7 +6767,7 @@
 
 For more examples that show how to use ``do_split_packages``, see the
 ``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
-directory of the ``poky`` :ref:`source repository <yocto-project-repositories>`. You can
+directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
 also find examples in ``meta/classes/kernel.bbclass``.
 
 Following is a reference that shows ``do_split_packages`` mandatory and
@@ -7077,8 +6938,6 @@
 and beyond the basics. The remainder of this section describes what you
 need to do.
 
-.. _runtime-package-management-build:
-
 Build Considerations
 ~~~~~~~~~~~~~~~~~~~~
 
@@ -7165,8 +7024,6 @@
 ``tmp`` and your selected package type is RPM, then your RPM packages
 are available in ``tmp/deploy/rpm``.
 
-.. _runtime-package-management-server:
-
 Host or Server Machine Setup
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7193,16 +7050,12 @@
    $ cd ~/poky/build/tmp/deploy/rpm
    $ python3 -m http.server
 
-.. _runtime-package-management-target:
-
 Target Setup
 ~~~~~~~~~~~~
 
 Setting up the target differs depending on the package management
 system. This section provides information for RPM, IPK, and DEB.
 
-.. _runtime-package-management-target-rpm:
-
 Using RPM
 ^^^^^^^^^
 
@@ -7283,8 +7136,6 @@
    See the `DNF documentation <https://dnf.readthedocs.io/en/latest/>`__ for
    additional information.
 
-.. _runtime-package-management-target-ipk:
-
 Using IPK
 ^^^^^^^^^
 
@@ -7325,8 +7176,6 @@
 The ``opkg`` application is now able to find, install, and upgrade packages
 from the specified repository.
 
-.. _runtime-package-management-target-deb:
-
 Using DEB
 ^^^^^^^^^
 
@@ -7462,7 +7311,7 @@
 the testname can be any identifying string.
 
 For a list of Yocto Project recipes that are already enabled with ptest,
-see the :yocto_wiki:`Ptest </wiki/Ptest>` wiki page.
+see the :yocto_wiki:`Ptest </Ptest>` wiki page.
 
 .. note::
 
@@ -7567,9 +7416,9 @@
 
 `NPM <https://en.wikipedia.org/wiki/Npm_(software)>`__ is a package
 manager for the JavaScript programming language. The Yocto Project
-supports the NPM :ref:`fetcher <bitbake:bb-fetchers>`. You can
+supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
 use this fetcher in combination with
-:doc:`devtool <../ref-manual/ref-devtool-reference>` to create
+:doc:`devtool </ref-manual/devtool-reference>` to create
 recipes that produce NPM packages.
 
 Two workflows exist that allow you to create NPM packages using
@@ -7583,8 +7432,6 @@
 
 Additionally, some requirements and caveats exist.
 
-.. _npm-package-creation-requirements:
-
 Requirements and Caveats
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7599,7 +7446,7 @@
    is NPM's public registry.
 
 -  Be familiar with
-   :doc:`devtool <../ref-manual/ref-devtool-reference>`.
+   :doc:`devtool </ref-manual/devtool-reference>`.
 
 -  The NPM host tools need the native ``nodejs-npm`` package, which is
    part of the OpenEmbedded environment. You need to get the package by
@@ -7619,8 +7466,6 @@
    useful to have NPM on your target. The NPM package name is
    ``nodejs-npm``.
 
-.. _npm-using-the-registry-modules-method:
-
 Using the Registry Modules Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7731,8 +7576,6 @@
 You can find the recipe in ``workspace/recipes/cute-files``. You can use
 the recipe in any layer you choose.
 
-.. _npm-using-the-npm-projects-method:
-
 Using the NPM Projects Code Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7956,8 +7799,6 @@
 and the appropriate packages will have support for both systemd and
 SysVinit.
 
-.. _selecting-dev-manager:
-
 Selecting a Device Manager
 ==========================
 
@@ -7974,8 +7815,6 @@
    configuration of device nodes is done in user space by a device
    manager like ``udev`` or ``busybox-mdev``.
 
-.. _static-dev-management:
-
 Using Persistent and Pre-Populated\ ``/dev``
 --------------------------------------------
 
@@ -8002,8 +7841,6 @@
 The population is handled by the ``makedevs`` utility during image
 creation:
 
-.. _devtmpfs-dev-management:
-
 Using ``devtmpfs`` and a Device Manager
 ---------------------------------------
 
@@ -8036,8 +7873,6 @@
    # VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
    # VIRTUAL-RUNTIME_dev_manager = "systemd"
 
-.. _platdev-appdev-srcrev:
-
 Using an External SCM
 =====================
 
@@ -8144,7 +7979,7 @@
    EXTRA_IMAGE_FEATURES = "read-only-rootfs"
 
 For more information on how to use these variables, see the
-":ref:`dev-manual/dev-manual-common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
+":ref:`dev-manual/common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
 section. For information on the variables, see
 :term:`IMAGE_FEATURES` and
 :term:`EXTRA_IMAGE_FEATURES`.
@@ -8221,13 +8056,13 @@
 
 The remainder of this section describes the following:
 
--  :ref:`How you can enable and disable build history <dev-manual/dev-manual-common-tasks:enabling and disabling build history>`
+-  :ref:`How you can enable and disable build history <dev-manual/common-tasks:enabling and disabling build history>`
 
--  :ref:`How to understand what the build history contains <dev-manual/dev-manual-common-tasks:understanding what the build history contains>`
+-  :ref:`How to understand what the build history contains <dev-manual/common-tasks:understanding what the build history contains>`
 
--  :ref:`How to limit the information used for build history <dev-manual/dev-manual-common-tasks:using build history to gather image information only>`
+-  :ref:`How to limit the information used for build history <dev-manual/common-tasks:using build history to gather image information only>`
 
--  :ref:`How to examine the build history from both a command-line and web interface <dev-manual/dev-manual-common-tasks:examining build history information>`
+-  :ref:`How to examine the build history from both a command-line and web interface <dev-manual/common-tasks:examining build history information>`
 
 Enabling and Disabling Build History
 ------------------------------------
@@ -8245,7 +8080,7 @@
 Enabling build history as
 previously described causes the OpenEmbedded build system to collect
 build output information and commit it as a single commit to a local
-:ref:`overview-manual/overview-manual-development-environment:git` repository.
+:ref:`overview-manual/development-environment:git` repository.
 
 .. note::
 
@@ -8598,7 +8433,7 @@
 
 To see changes to the build history using a web interface, follow the
 instruction in the ``README`` file
-:yocto_git:`here </cgit/cgit.cgi/buildhistory-web/>`.
+:yocto_git:`here </buildhistory-web/>`.
 
 Here is a sample screenshot of the interface:
 
@@ -8617,7 +8452,7 @@
 write and add your own tests.
 
 For information on the test and QA infrastructure available within the
-Yocto Project, see the ":ref:`ref-manual/ref-release-process:testing and quality assurance`"
+Yocto Project, see the ":ref:`ref-manual/release-process:testing and quality assurance`"
 section in the Yocto Project Reference Manual.
 
 Enabling Tests
@@ -8628,8 +8463,6 @@
 following subsections for information on how to enable both types of
 tests.
 
-.. _qemu-image-enabling-tests:
-
 Enabling Runtime Tests on QEMU
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -8714,8 +8547,6 @@
    You can find the output from the ``unittest`` in the task log at
    ``${WORKDIR}/temp/log.do_testimage``.
 
-.. _hardware-image-enabling-tests:
-
 Enabling Runtime Tests on Hardware
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -8931,8 +8762,6 @@
 
    TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
 
-.. _qemu-image-running-tests:
-
 Running Tests
 -------------
 
@@ -9077,8 +8906,6 @@
    $ cd tmp/testexport/core-image-sato
    $ ./runexported.py testdata.json
 
-.. _qemu-image-writing-new-tests:
-
 Writing New Tests
 -----------------
 
@@ -9110,8 +8937,6 @@
 is found in ``meta/lib/oetest.py``. This base class offers some helper
 attributes, which are described in the following sections:
 
-.. _qemu-image-writing-tests-class-methods:
-
 Class Methods
 ~~~~~~~~~~~~~
 
@@ -9125,8 +8950,6 @@
    :term:`IMAGE_FEATURES` or
    :term:`DISTRO_FEATURES`.
 
-.. _qemu-image-writing-tests-class-attributes:
-
 Class Attributes
 ~~~~~~~~~~~~~~~~
 
@@ -9174,8 +8997,6 @@
       -  *copy_from(remotepath, localpath):*
          ``scp root@host:remotepath localpath``.
 
-.. _qemu-image-writing-tests-instance-attributes:
-
 Instance Attributes
 ~~~~~~~~~~~~~~~~~~~
 
@@ -9241,8 +9062,6 @@
          ]
      }
 
-.. _usingpoky-debugging-tools-and-techniques:
-
 Debugging Tools and Techniques
 ==============================
 
@@ -9265,7 +9084,7 @@
    completes to log error information into a common database, that can
    help you figure out what might be going wrong. For information on how
    to enable and use this feature, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using the error reporting tool`"
+   ":ref:`dev-manual/common-tasks:using the error reporting tool`"
    section.
 
 The following list shows the debugging topics in the remainder of this
@@ -9281,7 +9100,7 @@
    use the BitBake ``-e`` option to examine variable values after a
    recipe has been parsed.
 
--  ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
+-  ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
    describes how to use the ``oe-pkgdata-util`` utility to query
    :term:`PKGDATA_DIR` and
    display package-related information for built packages.
@@ -9333,8 +9152,6 @@
 -  "`Other Debugging Tips <#dev-other-debugging-others>`__" describes
    miscellaneous debugging tips that can be useful.
 
-.. _dev-debugging-viewing-logs-from-failed-tasks:
-
 Viewing Logs from Failed Tasks
 ------------------------------
 
@@ -9354,8 +9171,6 @@
 when it ran. The symlinks always point to the files corresponding to the
 most recent run.
 
-.. _dev-debugging-viewing-variable-values:
-
 Viewing Variable Values
 -----------------------
 
@@ -9409,7 +9224,7 @@
 -  The output starts with a tree listing all configuration files and
    classes included globally, recursively listing the files they include
    or inherit in turn. Much of the behavior of the OpenEmbedded build
-   system (including the behavior of the :ref:`ref-manual/ref-tasks:normal recipe build tasks`) is
+   system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
    implemented in the
    :ref:`base <ref-classes-base>` class and the
    classes it inherits, rather than being built into BitBake itself.
@@ -9477,8 +9292,6 @@
    $ oe-pkgdata-util --help
    $ oe-pkgdata-util subcommand --help
 
-.. _dev-viewing-dependencies-between-recipes-and-tasks:
-
 Viewing Dependencies Between Recipes and Tasks
 ----------------------------------------------
 
@@ -9545,8 +9358,6 @@
 displays a GUI window from which you can view build-time and runtime
 dependencies for the recipes involved in building recipename.
 
-.. _dev-viewing-task-variable-dependencies:
-
 Viewing Task Variable Dependencies
 ----------------------------------
 
@@ -9583,7 +9394,7 @@
       ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
 
    For tasks that are accelerated through the shared state
-   (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, an
+   (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, an
    additional ``siginfo`` file is written into
    :term:`SSTATE_DIR` along with
    the cached task output. The ``siginfo`` files contain exactly the
@@ -9638,8 +9449,6 @@
 ``sigdata`` files in the ``stamps`` directory for every task it would
 have executed instead of building the specified target package.
 
-.. _dev-viewing-metadata-used-to-create-the-input-signature-of-a-shared-state-task:
-
 Viewing Metadata Used to Create the Input Signature of a Shared State Task
 --------------------------------------------------------------------------
 
@@ -9652,17 +9461,15 @@
 Dependencies <#dev-viewing-task-variable-dependencies>`__" section.
 
 For conceptual information on shared state, see the
-":ref:`overview-manual/overview-manual-concepts:shared state`"
+":ref:`overview-manual/concepts:shared state`"
 section in the Yocto Project Overview and Concepts Manual.
 
-.. _dev-invalidating-shared-state-to-force-a-task-to-run:
-
 Invalidating Shared State to Force a Task to Run
 ------------------------------------------------
 
 The OpenEmbedded build system uses
-:ref:`checksums <overview-checksums>` and
-:ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily
+:ref:`checksums <overview-manual/concepts:checksums (signatures)>` and
+:ref:`overview-manual/concepts:shared state` cache to avoid unnecessarily
 rebuilding tasks. Collectively, this scheme is known as "shared state
 code".
 
@@ -9701,9 +9508,7 @@
 
    For an example of a commit that makes a cosmetic change to invalidate
    shared state, see this
-   :yocto_git:`commit </cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
-
-.. _dev-debugging-taskrunning:
+   :yocto_git:`commit </poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
 
 Running Specific Tasks
 ----------------------
@@ -9725,7 +9530,7 @@
 depends on will be run before the task. Even when you manually specify a
 task to run with ``-c``, BitBake will only run the task if it considers
 it "out of date". See the
-":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
 section in the Yocto Project Overview and Concepts Manual for how
 BitBake determines whether a task is "out of date".
 
@@ -9759,7 +9564,7 @@
 therefore understands that the other tasks also need to be run again.
 
 Another, shorter way to rerun a task and all
-:ref:`ref-manual/ref-tasks:normal recipe build tasks`
+:ref:`ref-manual/tasks:normal recipe build tasks`
 that depend on it is to use the ``-C`` option.
 
 .. note::
@@ -9812,8 +9617,6 @@
 The results appear as output to the console and are also in
 the file ``${WORKDIR}/temp/log.do_listtasks``.
 
-.. _dev-debugging-bitbake:
-
 General BitBake Problems
 ------------------------
 
@@ -9827,8 +9630,6 @@
 provider. This command could also help you in a situation where you
 think BitBake did something unexpected.
 
-.. _dev-debugging-buildfile:
-
 Building with No Dependencies
 -----------------------------
 
@@ -10190,8 +9991,6 @@
 the Yocto Project <#how-to-submit-a-change>`__" section for more
 information.
 
-.. _platdev-gdb-remotedebug:
-
 Debugging With the GNU Project Debugger (GDB) Remotely
 ------------------------------------------------------
 
@@ -10199,7 +9998,7 @@
 understand and fix problems. It also allows you to perform post-mortem
 style analysis of program crashes. GDB is available as a package within
 the Yocto Project and is installed in SDK images by default. See the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+":ref:`ref-manual/images:Images`" chapter in the Yocto
 Project Reference Manual for a description of these images. You can find
 information on GDB at https://sourceware.org/gdb/.
 
@@ -10453,8 +10252,6 @@
    Consider that this will reduce the application's performance and is
    recommended only for debugging purposes.
 
-.. _dev-other-debugging-others:
-
 Other Debugging Tips
 --------------------
 
@@ -10520,7 +10317,7 @@
    Project implementation of
    :yocto_bugs:`Bugzilla <>`. For information on
    how to submit a bug against the Yocto Project, see the Yocto Project
-   Bugzilla :yocto_wiki:`wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
+   Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
    and the "`Submitting a Defect Against the Yocto
    Project <#submitting-a-defect-against-the-yocto-project>`__" section.
 
@@ -10548,7 +10345,7 @@
 Bugzilla <resources-bugtracker>`" section in the
 Yocto Project Reference Manual. For more detail on any of the following
 steps, see the Yocto Project
-:yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`.
+:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
 
 Use the following general steps to submit a bug:
 
@@ -10596,8 +10393,6 @@
 sending you an automated email concerning the particular change or
 progress to the bug.
 
-.. _how-to-submit-a-change:
-
 Submitting a Change to the Yocto Project
 ----------------------------------------
 
@@ -10662,7 +10457,8 @@
 
 You can also push a change upstream and request a maintainer to pull the
 change into the component's upstream repository. You do this by pushing
-to a contribution repository that is upstream. See the ":ref:`gs-git-workflows-and-the-yocto-project`"
+to a contribution repository that is upstream. See the
+":ref:`overview-manual/development-environment:git workflows and the yocto project`"
 section in the Yocto Project Overview and Concepts Manual for additional
 concepts on working in the Yocto Project development environment.
 
@@ -10676,7 +10472,7 @@
    proposed changes to the core metadata.
 
 -  *poky "master-next" branch:* This branch is part of the
-   :yocto_git:`poky </cgit/cgit.cgi/poky/>` repository and combines proposed
+   :yocto_git:`poky </poky/>` repository and combines proposed
    changes to bitbake, the core metadata and the poky distro.
 
 Similarly, stable branches maintained by the project may have corresponding
@@ -10690,8 +10486,6 @@
 
 The following sections provide procedures for submitting a change.
 
-.. _preparing-changes-for-submissions:
-
 Preparing Changes for Submission
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -10775,8 +10569,6 @@
 
          detailed description of change
 
-.. _submitting-a-patch:
-
 Using Email to Submit a Patch
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -10789,7 +10581,7 @@
 
 Here is the general procedure on how to submit a patch through email
 without using the scripts once the steps in
-:ref:`preparing-changes-for-submissions` have been followed:
+:ref:`dev-manual/common-tasks:preparing changes for submission` have been followed:
 
 1. *Format the Commit:* Format the commit into an email message. To
    format commits, use the ``git format-patch`` command. When you
@@ -10867,8 +10659,6 @@
    Asking about the status of a patch or change is reasonable if the change
    has been idle for a while with no feedback.
 
-.. _pushing-a-change-upstream:
-
 Using Scripts to Push a Change Upstream and Request a Pull
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -10880,7 +10670,7 @@
 patch series with a link to the branch for review.
 
 Follow this procedure to push a change to an upstream "contrib" Git
-repository once the steps in :ref:`preparing-changes-for-submissions` have
+repository once the steps in :ref:`dev-manual/common-tasks:preparing changes for submission` have
 been followed:
 
 .. note::
@@ -10917,7 +10707,7 @@
       located in the :term:`Source Directory` at
       ``meta/conf/distro/include``, to see who is responsible for code.
 
-   -  *Search by File:* Using :ref:`overview-manual/overview-manual-development-environment:git`, you can
+   -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
       enter the following command to bring up a short list of all
       commits against a specific file:
       ::
@@ -11019,7 +10809,7 @@
 
 The list of stable branches along with the status and maintainer for each
 branch can be obtained from the
-:yocto_wiki:`Releases wiki page </wiki/Releases>`.
+:yocto_wiki:`Releases wiki page </Releases>`.
 
 .. note::
 
@@ -11055,8 +10845,8 @@
       a newer version of the software which includes an upstream fix for the
       issue or when the issue has been fixed on the master branch in a way
       that introduces backwards incompatible changes. In this case follow the
-      steps in :ref:`preparing-changes-for-submissions` and
-      :ref:`submitting-a-patch` but modify the subject header of your patch
+      steps in :ref:`dev-manual/common-tasks:preparing changes for submission` and
+      :ref:`dev-manual/common-tasks:using email to submit a patch` but modify the subject header of your patch
       email to include the name of the stable branch which you are
       targetting. This can be done using the ``--subject-prefix`` argument to
       ``git format-patch``, for example to submit a patch to the dunfell
@@ -11066,7 +10856,7 @@
 Working With Licenses
 =====================
 
-As mentioned in the ":ref:`overview-manual/overview-manual-development-environment:licensing`"
+As mentioned in the ":ref:`overview-manual/development-environment:licensing`"
 section in the Yocto Project Overview and Concepts Manual, open source
 projects are open to the public and they consequently have different
 licensing structures in place. This section describes the mechanism by
@@ -11076,8 +10866,6 @@
 during your project's lifecycle. The section also describes how to
 enable commercially licensed recipes, which by default are disabled.
 
-.. _usingpoky-configuring-LIC_FILES_CHKSUM:
-
 Tracking License Changes
 ------------------------
 
@@ -11088,8 +10876,6 @@
 at the end of the configure step, and if the checksums do not match, the
 build will fail.
 
-.. _usingpoky-specifying-LIC_FILES_CHKSUM:
-
 Specifying the ``LIC_FILES_CHKSUM`` Variable
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -11133,8 +10919,6 @@
 Note that ``LIC_FILES_CHKSUM`` variable is mandatory for all recipes,
 unless the ``LICENSE`` variable is set to "CLOSED".
 
-.. _usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax:
-
 Explanation of Syntax
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -11515,7 +11299,7 @@
 used during the build, you will be providing both compilation scripts
 and the source code modifications in one step.
 
-If the deployment team has a :ref:`overview-manual/overview-manual-concepts:bsp layer`
+If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
 and a distro layer, and those
 those layers are used to patch, compile, package, or modify (in any way)
 any open source software included in your released images, you might be
@@ -11594,7 +11378,7 @@
       SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional
 
 For more usage information refer to :yocto_git:`the meta-spdxscanner repository
-</cgit/cgit.cgi/meta-spdxscanner/>`.
+</meta-spdxscanner/>`.
 
 
 Copying Licenses that Do Not Exist
@@ -11700,11 +11484,9 @@
 ------------------------------------------
 
 If you want to set up your own error reporting server, you can obtain
-the code from the Git repository at :yocto_git:`/cgit/cgit.cgi/error-report-web/`.
+the code from the Git repository at :yocto_git:`/error-report-web/`.
 Instructions on how to set it up are in the README document.
 
-.. _dev-using-wayland-and-weston:
-
 Using Wayland and Weston
 ========================
 
@@ -11747,8 +11529,6 @@
 To enable Wayland, you need to enable it to be built and enable it to be
 included (installed) in the image.
 
-.. _enable-building:
-
 Building Wayland
 ~~~~~~~~~~~~~~~~
 
@@ -11767,8 +11547,6 @@
    If X11 has been enabled elsewhere, Weston will build Wayland with X11
    support
 
-.. _enable-installation-in-an-image:
-
 Installing Wayland and Weston
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/poky/documentation/dev-manual/dev-manual.rst b/poky/documentation/dev-manual/index.rst
similarity index 75%
rename from poky/documentation/dev-manual/dev-manual.rst
rename to poky/documentation/dev-manual/index.rst
index 8f09224..941db2d 100644
--- a/poky/documentation/dev-manual/dev-manual.rst
+++ b/poky/documentation/dev-manual/index.rst
@@ -10,10 +10,10 @@
    :caption: Table of Contents
    :numbered:
 
-   dev-manual-intro
-   dev-manual-start
-   dev-manual-common-tasks
-   dev-manual-qemu
+   intro
+   start
+   common-tasks
+   qemu
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/dev-manual/dev-manual-intro.rst b/poky/documentation/dev-manual/intro.rst
similarity index 92%
rename from poky/documentation/dev-manual/dev-manual-intro.rst
rename to poky/documentation/dev-manual/intro.rst
index 05136f7..23c848e 100644
--- a/poky/documentation/dev-manual/dev-manual-intro.rst
+++ b/poky/documentation/dev-manual/intro.rst
@@ -4,8 +4,6 @@
 The Yocto Project Development Tasks Manual
 ******************************************
 
-.. _dev-welcome:
-
 Welcome
 =======
 
@@ -33,13 +31,13 @@
 This manual does not provide the following:
 
 -  Redundant Step-by-step Instructions: For example, the
-   :doc:`../sdk-manual/sdk-manual` manual contains detailed
+   :doc:`/sdk-manual/index` manual contains detailed
    instructions on how to install an SDK, which is used to develop
    applications for target hardware.
 
 -  Reference or Conceptual Material: This type of material resides in an
    appropriate reference manual. For example, system variables are
-   documented in the :doc:`../ref-manual/ref-manual`.
+   documented in the :doc:`/ref-manual/index`.
 
 -  Detailed Public Information Not Specific to the Yocto Project: For
    example, exhaustive information on how to use the Source Control
@@ -54,7 +52,7 @@
 introductory information on the Yocto Project, see the
 :yocto_home:`Yocto Project Website <>`. If you want to build an image with no
 knowledge of Yocto Project as a way of quickly testing it out, see the
-:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+:doc:`/brief-yoctoprojectqs/index` document.
 
 For a comprehensive list of links and other documentation, see the
 ":ref:`ref-manual/resources:links and related documentation`"
diff --git a/poky/documentation/dev-manual/dev-manual-qemu.rst b/poky/documentation/dev-manual/qemu.rst
similarity index 97%
rename from poky/documentation/dev-manual/dev-manual-qemu.rst
rename to poky/documentation/dev-manual/qemu.rst
index c91e8b5..766691b 100644
--- a/poky/documentation/dev-manual/dev-manual-qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -10,8 +10,6 @@
 EMUlator (QEMU) and other QEMU information helpful for development
 purposes.
 
-.. _qemu-dev-overview:
-
 Overview
 ========
 
@@ -39,8 +37,6 @@
 -  `Documentation <https://wiki.qemu.org/Manual>`__\ *:* The QEMU user
    manual.
 
-.. _qemu-running-qemu:
-
 Running QEMU
 ============
 
@@ -50,7 +46,7 @@
 
 1. *Install QEMU:* QEMU is made available with the Yocto Project a
    number of ways. One method is to install a Software Development Kit
-   (SDK). See ":ref:`sdk-manual/sdk-intro:the qemu emulator`" section in the
+   (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the
    Yocto Project Application Development and the Extensible Software
    Development Kit (eSDK) manual for information on how to install QEMU.
 
@@ -81,11 +77,11 @@
       your :term:`Build Directory`.
 
    -  If you have not built an image, you can go to the
-      :yocto_dl:`machines/qemu </releases/yocto/yocto-3.1.2/machines/qemu/>` area and download a
+      :yocto_dl:`machines/qemu </releases/yocto/yocto-&DISTRO;/machines/qemu/>` area and download a
       pre-built image that matches your architecture and can be run on
       QEMU.
 
-   See the ":ref:`sdk-manual/sdk-appendix-obtain:extracting the root filesystem`"
+   See the ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
    section in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual for information on
    how to extract a root filesystem.
@@ -187,8 +183,6 @@
 can enter and leave the main window without the grab taking effect
 leading to a better user experience.
 
-.. _qemu-running-under-a-network-file-system-nfs-server:
-
 Running Under a Network File System (NFS) Server
 ================================================
 
@@ -243,8 +237,6 @@
 
          runqemu-export-rootfs restart file-system-location
 
-.. _qemu-kvm-cpu-compatibility:
-
 QEMU CPU Compatibility Under KVM
 ================================
 
@@ -266,8 +258,6 @@
 the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
 available supported CPU types.
 
-.. _qemu-dev-performance:
-
 QEMU Performance
 ================
 
@@ -320,8 +310,6 @@
       Server <#qemu-running-under-a-network-file-system-nfs-server>`__"
       section for more information.
 
-.. _qemu-dev-command-line-syntax:
-
 QEMU Command-Line Syntax
 ========================
 
@@ -377,8 +365,6 @@
      runqemu path/to/<image>-<machine>.wic
      runqemu path/to/<image>-<machine>.wic.vmdk
 
-.. _qemu-dev-runqemu-command-line-options:
-
 ``runqemu`` Command-Line Options
 ================================
 
diff --git a/poky/documentation/dev-manual/dev-manual-start.rst b/poky/documentation/dev-manual/start.rst
similarity index 92%
rename from poky/documentation/dev-manual/dev-manual-start.rst
rename to poky/documentation/dev-manual/start.rst
index a85b86f..03061a7 100644
--- a/poky/documentation/dev-manual/dev-manual-start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -7,12 +7,10 @@
 This chapter provides guidance on how to prepare to use the Yocto
 Project. You can learn about creating a team environment to develop
 using the Yocto Project, how to set up a :ref:`build
-host <dev-manual/dev-manual-start:preparing the build host>`, how to locate
+host <dev-manual/start:preparing the build host>`, how to locate
 Yocto Project source repositories, and how to create local Git
 repositories.
 
-.. _usingpoky-changes-collaborate:
-
 Creating a Team Development Environment
 =======================================
 
@@ -80,7 +78,7 @@
     developing under the control of an SCM system that is compatible
     with the OpenEmbedded build system is advisable. Of all of the SCMs
     supported by BitBake, the Yocto Project team strongly recommends using
-    :ref:`overview-manual/overview-manual-development-environment:git`.
+    :ref:`overview-manual/development-environment:git`.
     Git is a distributed system
     that is easy to back up, allows you to work remotely, and then
     connects back to the infrastructure.
@@ -167,7 +165,7 @@
     -  Highlights when commits break the build.
 
     -  Populates an :ref:`sstate
-       cache <overview-manual/overview-manual-concepts:shared state cache>` from which
+       cache <overview-manual/concepts:shared state cache>` from which
        developers can pull rather than requiring local builds.
 
     -  Allows commit hook triggers, which trigger builds when commits
@@ -220,17 +218,17 @@
     some best practices exist within the Yocto Project development
     environment. Consider the following:
 
-    -  Use :ref:`overview-manual/overview-manual-development-environment:git` as the source control
+    -  Use :ref:`overview-manual/development-environment:git` as the source control
        system.
 
     -  Maintain your Metadata in layers that make sense for your
-       situation. See the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+       situation. See the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
        section in the Yocto Project Overview and Concepts Manual and the
-       ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+       ":ref:`dev-manual/common-tasks:understanding and creating layers`"
        section for more information on layers.
 
     -  Separate the project's Metadata and code by using separate Git
-       repositories. See the ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+       repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`"
        section in the Yocto Project Overview and Concepts Manual for
        information on these repositories. See the "`Locating Yocto
        Project Source Files <#locating-yocto-project-source-files>`__"
@@ -250,19 +248,17 @@
        project to fix bugs or add features. If you do submit patches,
        follow the project commit guidelines for writing good commit
        messages. See the
-       ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+       ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
        section.
 
     -  Send changes to the core sooner than later as others are likely
        to run into the same issues. For some guidance on mailing lists
        to use, see the list in the
-       ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+       ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
        section. For a description
        of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
        the Yocto Project Reference Manual.
 
-.. _dev-preparing-the-build-host:
-
 Preparing the Build Host
 ========================
 
@@ -292,7 +288,7 @@
    section in the Yocto Project Board Support Package (BSP) Developer's
    Guide.
 
--  *Kernel Development:* See the ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+-  *Kernel Development:* See the ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
    section in the Yocto Project Linux Kernel Development Manual.
 
 Setting Up a Native Linux Host
@@ -309,7 +305,7 @@
    validation and their status, see the ":ref:`Supported Linux
    Distributions <detailed-supported-distros>`"
    section in the Yocto Project Reference Manual and the wiki page at
-   :yocto_wiki:`Distribution Support </wiki/Distribution_Support>`.
+   :yocto_wiki:`Distribution Support </Distribution_Support>`.
 
 2. *Have Enough Free Memory:* Your system should have at least 50 Gbytes
    of free disk space for building images.
@@ -329,7 +325,7 @@
    If your build host does not meet any of these three listed version
    requirements, you can take steps to prepare the system so that you
    can still use the Yocto Project. See the
-   ":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+   ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
    section in the Yocto Project Reference Manual for information.
 
 4. *Install Development Host Packages:* Required development host
@@ -338,22 +334,20 @@
    is large if you want to be able to cover all cases.
 
    For lists of required packages for all scenarios, see the
-   ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+   ":ref:`ref-manual/system-requirements:required packages for the build host`"
    section in the Yocto Project Reference Manual.
 
 Once you have completed the previous steps, you are ready to continue
 using a given development path on your native Linux machine. If you are
 going to use BitBake, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
 section. If you are going
-to use the Extensible SDK, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
-Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`../kernel-dev/kernel-dev`. If you are going to use
-Toaster, see the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
+Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
-.. _setting-up-to-use-crops:
-
 Setting Up to Use CROss PlatformS (CROPS)
 -----------------------------------------
 
@@ -446,16 +440,14 @@
 Once you have a container set up, everything is in place to develop just
 as if you were running on a native Linux machine. If you are going to
 use the Poky container, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
 section. If you are going to use the Extensible SDK container, see the
-":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
-.. _setting-up-to-use-wsl:
-
 Setting Up to Use Windows Subsystem For Linux (WSLv2)
 -----------------------------------------------------
 
@@ -565,10 +557,10 @@
 
 Once you have WSLv2 set up, everything is in place to develop just as if
 you were running on a native Linux machine. If you are going to use the
-Extensible SDK container, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
 Locating Yocto Project Source Files
@@ -580,21 +572,21 @@
 .. note::
 
    -  For concepts and introductory information about Git as it is used
-      in the Yocto Project, see the ":ref:`overview-manual/overview-manual-development-environment:git`"
+      in the Yocto Project, see the ":ref:`overview-manual/development-environment:git`"
       section in the Yocto Project Overview and Concepts Manual.
 
    -  For concepts on Yocto Project source repositories, see the
-      ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+      ":ref:`overview-manual/development-environment:yocto project source repositories`"
       section in the Yocto Project Overview and Concepts Manual."
 
 Accessing Source Repositories
 -----------------------------
 
-Working from a copy of the upstream :ref:`dev-manual/dev-manual-start:accessing source repositories` is the
+Working from a copy of the upstream :ref:`dev-manual/start:accessing source repositories` is the
 preferred method for obtaining and using a Yocto Project release. You
 can view the Yocto Project Source Repositories at
 :yocto_git:`/`. In particular, you can find the ``poky``
-repository at :yocto_git:`/cgit.cgi/poky`.
+repository at :yocto_git:`/poky`.
 
 Use the following procedure to locate the latest upstream copy of the
 ``poky`` Git repository:
@@ -608,12 +600,12 @@
 
 3. *Find the URL Used to Clone the Repository:* At the bottom of the
    page, note the URL used to clone that repository
-   (e.g. :yocto_git:`/cgit.cgi/poky`).
+   (e.g. :yocto_git:`/poky`).
 
    .. note::
 
       For information on cloning a repository, see the
-      ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" section.
+      ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
 
 Accessing Index of Releases
 ---------------------------
@@ -686,7 +678,7 @@
    .. note::
 
       For a "map" of Yocto Project releases to version numbers, see the
-      :yocto_wiki:`Releases </wiki/Releases>` wiki page.
+      :yocto_wiki:`Releases </Releases>` wiki page.
 
    You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
    Project releases.
@@ -730,7 +722,7 @@
 in the Yocto Project documentation.
 
 The preferred method of creating your Source Directory is by using
-:ref:`overview-manual/overview-manual-development-environment:git` to clone a local copy of the upstream
+:ref:`overview-manual/development-environment:git` to clone a local copy of the upstream
 ``poky`` repository. Working from a cloned copy of the upstream
 repository allows you to contribute back into the Yocto Project or to
 simply work with the latest software on a development branch. Because
@@ -809,7 +801,7 @@
 1. *Switch to the Poky Directory:* If you have a local poky Git
    repository, switch to that directory. If you do not have the local
    copy of poky, see the
-   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
    section.
 
 2. *Determine Existing Branch Names:*
@@ -855,8 +847,6 @@
         master
         * &DISTRO_NAME_NO_CAP;
 
-.. _checkout-out-by-tag-in-poky:
-
 Checking Out by Tag in Poky
 ---------------------------
 
@@ -874,7 +864,7 @@
 1. *Switch to the Poky Directory:* If you have a local poky Git
    repository, switch to that directory. If you do not have the local
    copy of poky, see the
-   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
    section.
 
 2. *Fetch the Tag Names:* To checkout the branch based on a tag name,
diff --git a/poky/documentation/index.rst b/poky/documentation/index.rst
index 2891a98..9f41daf 100644
--- a/poky/documentation/index.rst
+++ b/poky/documentation/index.rst
@@ -14,7 +14,7 @@
    :maxdepth: 1
    :caption: Introduction and Overview
 
-   Quick Build <brief-yoctoprojectqs/brief-yoctoprojectqs>
+   Quick Build <brief-yoctoprojectqs/index>
    what-i-wish-id-known
    transitioning-to-a-custom-environment
    Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/>
@@ -25,15 +25,15 @@
    :maxdepth: 1
    :caption: Manuals
 
-   Overview and Concepts Manual <overview-manual/overview-manual>
-   Reference Manual <ref-manual/ref-manual>
-   Board Support Package (BSP) Developer's guide <bsp-guide/bsp-guide>
-   Development Tasks Manual <dev-manual/dev-manual>
-   Linux Kernel Development Manual <kernel-dev/kernel-dev>
-   Profile and Tracing Manual <profile-manual/profile-manual>
-   Application Development and the Extensible SDK (eSDK) <sdk-manual/sdk-manual>
-   Toaster Manual <toaster-manual/toaster-manual>
-   Test Environment Manual <test-manual/test-manual>
+   Overview and Concepts Manual <overview-manual/index>
+   Reference Manual <ref-manual/index>
+   Board Support Package (BSP) Developer's guide <bsp-guide/index>
+   Development Tasks Manual <dev-manual/index>
+   Linux Kernel Development Manual <kernel-dev/index>
+   Profile and Tracing Manual <profile-manual/index>
+   Application Development and the Extensible SDK (eSDK) <sdk-manual/index>
+   Toaster Manual <toaster-manual/index>
+   Test Environment Manual <test-manual/index>
    Bitbake User Manual <https://docs.yoctoproject.org/bitbake>
 
 .. toctree::
diff --git a/poky/documentation/kernel-dev/kernel-dev-advanced.rst b/poky/documentation/kernel-dev/advanced.rst
similarity index 96%
rename from poky/documentation/kernel-dev/kernel-dev-advanced.rst
rename to poky/documentation/kernel-dev/advanced.rst
index ca04931..dd0b76b 100644
--- a/poky/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -16,7 +16,7 @@
 BSPs and Linux kernel types.
 
 Kernel Metadata exists in many places. One area in the
-:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+:ref:`overview-manual/development-environment:yocto project source repositories`
 is the ``yocto-kernel-cache`` Git repository. You can find this repository
 grouped under the "Yocto Linux Kernel" heading in the
 :yocto_git:`Yocto Project Source Repositories <>`.
@@ -200,7 +200,7 @@
 :term:`FILESEXTRAPATHS` if
 you are creating Metadata in `recipe-space <#recipe-space-metadata>`__,
 or the top level of
-:yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache/tree/>`
+:yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/>`
 if you are creating `Metadata outside of the
 recipe-space <#metadata-outside-the-recipe-space>`__.
 
@@ -243,7 +243,7 @@
       CONFIG_X86_BIGSMP=y
 
 You can find general information on configuration
-fragment files in the ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section.
+fragment files in the ":ref:`kernel-dev/common:creating configuration fragments`" section.
 
 Within the ``smp.scc`` file, the
 :term:`KFEATURE_DESCRIPTION`
@@ -264,7 +264,7 @@
    fragment.
 
 As described in the
-":ref:`kernel-dev/kernel-dev-common:validating configuration`" section, you can
+":ref:`kernel-dev/common:validating configuration`" section, you can
 use the following BitBake command to audit your configuration:
 ::
 
@@ -325,8 +325,8 @@
 
 You can create a typical ``.patch`` file using ``diff -Nurp`` or
 ``git format-patch`` commands. For information on how to create patches,
-see the ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
-and ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+see the ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
+and ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 sections.
 
 Features
@@ -369,7 +369,7 @@
 variable in the kernel recipe selects the kernel type. For example, in
 the ``linux-yocto_4.12.bb`` kernel recipe found in
 ``poky/meta/recipes-kernel/linux``, a
-:ref:`require <bitbake:require-inclusion>` directive
+:ref:`require <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` directive
 includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
 which has the following statement that defines the default kernel type:
 ::
@@ -386,9 +386,9 @@
 .. note::
 
    You can find kernel recipes in the ``meta/recipes-kernel/linux`` directory
-   of the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+   of the :ref:`overview-manual/development-environment:yocto project source repositories`
    (e.g. ``poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb``). See the
-   ":ref:`kernel-dev/kernel-dev-advanced:using kernel metadata in a recipe`"
+   ":ref:`kernel-dev/advanced:using kernel metadata in a recipe`"
    section for more information.
 
 Three kernel types ("standard", "tiny", and "preempt-rt") are supported
@@ -453,7 +453,7 @@
    It is not strictly necessary to create a kernel type ``.scc``
    file. The Board Support Package (BSP) file can implicitly define the
    kernel type using a ``define`` :term:`KTYPE` ``myktype`` line. See the
-   ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`" section for more
+   ":ref:`kernel-dev/advanced:bsp descriptions`" section for more
    information.
 
 BSP Descriptions
@@ -469,12 +469,12 @@
    For BSPs supported by the Yocto Project, the BSP description files
    are located in the ``bsp`` directory of the ``yocto-kernel-cache``
    repository organized under the "Yocto Linux Kernel" heading in the
-   :yocto_git:`Yocto Project Source Repositories </>`.
+   :yocto_git:`Yocto Project Source Repositories <>`.
 
 This section overviews the BSP description structure, the aggregation
 concepts, and presents a detailed example using a BSP supported by the
 Yocto Project (i.e. BeagleBone Board). For complete information on BSP
-layer file hierarchy, see the :doc:`../bsp-guide/bsp-guide`.
+layer file hierarchy, see the :doc:`/bsp-guide/index`.
 
 Description Overview
 ~~~~~~~~~~~~~~~~~~~~
@@ -555,7 +555,7 @@
    include beaglebone.scc
 
 For information on how to break a complete ``.config`` file into the various
-configuration fragments, see the ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section.
+configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section.
 
 Finally, if you have any configurations specific to the hardware that
 are not in a ``*.scc`` file, you can include them as follows:
@@ -696,7 +696,7 @@
 control or if you just do not want to maintain a Linux kernel Git
 repository on your own. For partial information on how you can define
 kernel Metadata in the recipe-space, see the
-":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`" section.
+":ref:`kernel-dev/common:modifying an existing recipe`" section.
 
 Conversely, if you are actively developing a kernel and are already
 maintaining a Linux kernel Git repository of your own, you might find it
@@ -716,7 +716,7 @@
 ``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
 a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to
 ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
-See the ":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`"
+See the ":ref:`kernel-dev/common:modifying an existing recipe`"
 section for more information.
 
 Here is an example that shows a trivial tree of kernel Metadata stored
diff --git a/poky/documentation/kernel-dev/kernel-dev-common.rst b/poky/documentation/kernel-dev/common.rst
similarity index 95%
rename from poky/documentation/kernel-dev/kernel-dev-common.rst
rename to poky/documentation/kernel-dev/common.rst
index 72d9d78..6691da4 100644
--- a/poky/documentation/kernel-dev/kernel-dev-common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -21,11 +21,11 @@
 
 Before you can do any kernel development, you need to be sure your build
 host is set up to use the Yocto Project. For information on how to get
-set up, see the ":doc:`../dev-manual/dev-manual-start`" section in
+set up, see the ":doc:`/dev-manual/start`" section in
 the Yocto Project Development Tasks Manual. Part of preparing the system
 is creating a local Git repository of the
 :term:`Source Directory` (``poky``) on your system. Follow the steps in the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
 section in the Yocto Project Development Tasks Manual to set up your
 Source Directory.
 
@@ -34,12 +34,12 @@
    Be sure you check out the appropriate development branch or you
    create your local branch by checking out a specific tag to get the
    desired version of Yocto Project. See the
-   ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
-   ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
+   ":ref:`dev-manual/start:checking out by branch in poky`" and
+   ":ref:`dev-manual/start:checking out by tag in poky`"
    sections in the Yocto Project Development Tasks Manual for more information.
 
 Kernel development is best accomplished using
-:ref:`devtool <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+:ref:`devtool <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
 and not through traditional kernel workflow methods. The remainder of
 this section provides information for both scenarios.
 
@@ -49,7 +49,7 @@
 Follow these steps to prepare to update the kernel image using
 ``devtool``. Completing this procedure leaves you with a clean kernel
 image and ready to make modifications as described in the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
 section:
 
 1. *Initialize the BitBake Environment:* Before building an extensible
@@ -63,7 +63,7 @@
    .. note::
 
       The previous commands assume the
-      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+      :ref:`overview-manual/development-environment:yocto project source repositories`
       (i.e. ``poky``) have been cloned using Git and the local repository is named
       "poky".
 
@@ -104,13 +104,13 @@
 
       For background information on working with common and BSP layers,
       see the
-      ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+      ":ref:`dev-manual/common-tasks:understanding and creating layers`"
       section in the Yocto Project Development Tasks Manual and the
       ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
       Support (BSP) Developer's Guide, respectively. For information on how to
       use the ``bitbake-layers create-layer`` command to quickly set up a layer,
       see the
-      ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
       section in the Yocto Project Development Tasks Manual.
 
 4. *Inform the BitBake Build Environment About Your Layer:* As directed
@@ -147,8 +147,8 @@
    ::
 
       $ cd ~/poky/build/tmp/deploy/sdk
-      $ ./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-3.1.2.sh
-      Poky (Yocto Project Reference Distro) Extensible SDK installer version 3.1.2
+      $ ./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-&DISTRO;.sh
+      Poky (Yocto Project Reference Distro) Extensible SDK installer version &DISTRO;
       ============================================================================
       Enter target directory for SDK (default: ~/poky_sdk):
       You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed [Y/n]? Y
@@ -207,12 +207,12 @@
    building for actual hardware and not for emulation, you could flash
    the image to a USB stick on ``/dev/sdd`` and boot your device. For an
    example that uses a Minnowboard, see the
-   :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`
+   :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </TipsAndTricks/KernelDevelopmentWithEsdk>`
    Wiki page.
 
 At this point you have set up to start making modifications to the
 kernel by using the extensible SDK. For a continued example, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
 section.
 
 Getting Ready for Traditional Kernel Development
@@ -226,7 +226,7 @@
 Follow these steps to prepare to update the kernel image using
 traditional kernel development flow with the Yocto Project. Completing
 this procedure leaves you ready to make modifications to the kernel
-source as described in the ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+source as described in the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 section:
 
 1. *Initialize the BitBake Environment:* Before you can do anything
@@ -236,7 +236,7 @@
    Also, for this example, be sure that the local branch you have
    checked out for ``poky`` is the Yocto Project &DISTRO_NAME; branch. If
    you need to checkout out the &DISTRO_NAME; branch, see the
-   ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`"
+   ":ref:`dev-manual/start:checking out by branch in poky`"
    section in the Yocto Project Development Tasks Manual.
    ::
 
@@ -249,7 +249,7 @@
    .. note::
 
       The previous commands assume the
-      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+      :ref:`overview-manual/development-environment:yocto project source repositories`
       (i.e. ``poky``) have been cloned using Git and the local repository is named
       "poky".
 
@@ -289,13 +289,13 @@
 
       For background information on working with common and BSP layers,
       see the
-      ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+      ":ref:`dev-manual/common-tasks:understanding and creating layers`"
       section in the Yocto Project Development Tasks Manual and the
       ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
       Support (BSP) Developer's Guide, respectively. For information on how to
       use the ``bitbake-layers create-layer`` command to quickly set up a layer,
       see the
-      ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
       section in the Yocto Project Development Tasks Manual.
 
 4. *Inform the BitBake Build Environment About Your Layer:* As directed
@@ -378,7 +378,7 @@
 append files (``.bbappend``) and provides a convenient mechanism to
 create your own recipe files (``.bb``) as well as store and use kernel
 patch files. For background information on working with layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section in the Yocto Project Development Tasks Manual.
 
 .. note::
@@ -386,7 +386,7 @@
    The Yocto Project comes with many tools that simplify tasks you need
    to perform. One such tool is the ``bitbake-layers create-layer``
    command, which simplifies creating a new layer. See the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
    section in the Yocto Project Development Tasks Manual for
    information on how to use this script to quick set up a new layer.
 
@@ -443,7 +443,7 @@
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find patch files. For more
    information on using append files, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+   ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
    section in the Yocto Project Development Tasks Manual.
 
 Modifying an Existing Recipe
@@ -457,11 +457,11 @@
 
 Modifying an existing recipe can consist of the following:
 
-- :ref:`kernel-dev/kernel-dev-common:creating the append file`
+- :ref:`kernel-dev/common:creating the append file`
 
-- :ref:`kernel-dev/kernel-dev-common:applying patches`
+- :ref:`kernel-dev/common:applying patches`
 
-- :ref:`kernel-dev/kernel-dev-common:changing the configuration`
+- :ref:`kernel-dev/common:changing the configuration`
 
 Before modifying an existing recipe, be sure that you have created a
 minimal, custom layer from which you can work. See the "`Creating and
@@ -502,7 +502,7 @@
 .. note::
 
    If you are working on a new machine Board Support Package (BSP), be
-   sure to refer to the :doc:`../bsp-guide/bsp-guide`.
+   sure to refer to the :doc:`/bsp-guide/index`.
 
 As an example, consider the following append file used by the BSPs in
 ``meta-yocto-bsp``:
@@ -642,9 +642,9 @@
 
 For a detailed example showing how to patch the kernel using
 ``devtool``, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
 and
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 sections.
 
 Changing the Configuration
@@ -769,7 +769,7 @@
 
    Before attempting this procedure, be sure you have performed the
    steps to get ready for updating the kernel as described in the
-   ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+   ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
    section.
 
 Patching the kernel involves changing or adding configurations to an
@@ -782,7 +782,7 @@
 ``calibrate.c`` source code file. Applying the patch and booting the
 modified image causes the added messages to appear on the emulator's
 console. The example is a continuation of the setup procedure found in
-the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``" Section.
+the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section.
 
 1. *Check Out the Kernel Source Files:* First you must use ``devtool``
    to checkout the kernel source code in its workspace. Be sure you are
@@ -791,7 +791,7 @@
    .. note::
 
       See this step in the
-      ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+      ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
       section for more information.
 
    Use the following ``devtool`` command to check out the code:
@@ -862,7 +862,7 @@
       If the image you originally created resulted in a Wic file, you
       can use an alternate method to create the new image with the
       updated kernel. For an example, see the steps in the
-      :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`
+      :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </TipsAndTricks/KernelDevelopmentWithEsdk>`
       Wiki Page.
 
    ::
@@ -912,7 +912,7 @@
    .. note::
 
       See Step 3 of the
-      ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+      ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
       section for information on setting up this layer.
 
    Once the command
@@ -935,14 +935,14 @@
 The steps in this procedure show you how you can patch the kernel using
 traditional kernel development (i.e. not using ``devtool`` and the
 extensible SDK as described in the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
 section).
 
 .. note::
 
    Before attempting this procedure, be sure you have performed the
    steps to get ready for updating the kernel as described in the
-   ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
+   ":ref:`kernel-dev/common:getting ready for traditional kernel development`"
    section.
 
 Patching the kernel involves changing or adding configurations to an
@@ -1108,7 +1108,7 @@
    For more information on append files and patches, see the "`Creating
    the Append File <#creating-the-append-file>`__" and "`Applying
    Patches <#applying-patches>`__" sections. You can also see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+   ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
    section in the Yocto Project Development Tasks Manual.
 
    .. note::
@@ -1190,9 +1190,9 @@
 
    You can use the entire ``.config`` file as the ``defconfig`` file. For
    information on ``defconfig`` files, see the
-   ":ref:`kernel-dev/kernel-dev-common:changing the configuration`",
-   ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`",
-   and ":ref:`kernel-dev/kernel-dev-common:creating a \`\`defconfig\`\` file`"
+   ":ref:`kernel-dev/common:changing the configuration`",
+   ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`",
+   and ":ref:`kernel-dev/common:creating a \`\`defconfig\`\` file`"
    sections.
 
 Consider an example that configures the "CONFIG_SMP" setting for the
@@ -1320,7 +1320,7 @@
 
    For more information about where the ``.config`` file is located, see the
    example in the
-   ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+   ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
    section.
 
 It is simple to create a configuration fragment. One method is to use
@@ -1377,7 +1377,7 @@
 .. note::
 
    You can also use this method to create configuration fragments for a
-   BSP. See the ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`"
+   BSP. See the ":ref:`kernel-dev/advanced:bsp descriptions`"
    section for more information.
 
 Where do you put your configuration fragment files? You can place these
@@ -1423,7 +1423,7 @@
 fragment.
 
 In order to run this task, you must have an existing ``.config`` file.
-See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``" section for
+See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
 information on how to create a configuration file.
 
 Following is sample output from the ``do_kernel_configcheck`` task:
@@ -1496,7 +1496,7 @@
 tasks until they produce no warnings.
 
 For more information on how to use the ``menuconfig`` tool, see the
-:ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\`` section.
+:ref:`kernel-dev/common:using \`\`menuconfig\`\`` section.
 
 Fine-Tuning the Kernel Configuration File
 -----------------------------------------
@@ -1612,7 +1612,7 @@
    Depending on your particular kernel development workflow, the
    commands you use to rebuild the kernel might differ. For information
    on building the kernel image when using ``devtool``, see the
-   ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+   ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
    section. For
    information on building the kernel image when using Bitbake, see the
    "`Using Traditional Kernel Development to Patch the
@@ -1942,7 +1942,7 @@
 ===================================
 
 You can add kernel features in the
-:ref:`recipe-space <kernel-dev/kernel-dev-advanced:recipe-space metadata>`
+:ref:`recipe-space <kernel-dev/advanced:recipe-space metadata>`
 by using the :term:`KERNEL_FEATURES`
 variable and by specifying the feature's ``.scc`` file path in the
 :term:`SRC_URI` statement. When you
@@ -1961,7 +1961,7 @@
 ``SRC_URI`` statement regardless of whether the Metadata is in the
 "kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
 part of the kernel recipe). See the
-":ref:`kernel-dev/kernel-dev-advanced:kernel metadata location`" section for
+":ref:`kernel-dev/advanced:kernel metadata location`" section for
 additional information.
 
 When you specify the feature's ``.scc`` file on the ``SRC_URI``
diff --git a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/poky/documentation/kernel-dev/concepts-appx.rst
similarity index 95%
rename from poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
rename to poky/documentation/kernel-dev/concepts-appx.rst
index 470d6ce..4b6dbe5 100644
--- a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/poky/documentation/kernel-dev/concepts-appx.rst
@@ -35,7 +35,7 @@
 needs for targeted hardware.
 
 You can find a web interface to the Yocto Linux kernels in the
-:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+:ref:`overview-manual/development-environment:yocto project source repositories`
 at :yocto_git:`/`. If you look at the interface, you will see to
 the left a grouping of Git repositories titled "Yocto Linux Kernel".
 Within this group, you will find several Linux Yocto kernels developed
@@ -71,7 +71,7 @@
    and configurations for the linux-yocto kernel tree. This repository
    is useful when working on the linux-yocto kernel. For more
    information on this "Advanced Kernel Metadata", see the
-   ":doc:`kernel-dev-advanced`" Chapter.
+   ":doc:`/kernel-dev/advanced`" Chapter.
 
 -  *linux-yocto-dev:* A development kernel based on the latest
    upstream release candidate available.
@@ -160,7 +160,7 @@
 
    -  You can find documentation on Git at https://git-scm.com/doc. You can
       also get an introduction to Git as it applies to the Yocto Project in the
-      ":ref:`overview-manual/overview-manual-development-environment:git`" section in the Yocto Project
+      ":ref:`overview-manual/development-environment:git`" section in the Yocto Project
       Overview and Concepts Manual. The latter reference provides an
       overview of Git and presents a minimal set of Git commands that
       allows you to be functional using Git. You can use as much, or as
@@ -258,7 +258,7 @@
    Yocto Linux kernels, but rather shows a single generic kernel just
    for conceptual purposes. Also keep in mind that this structure
    represents the
-   :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+   :ref:`overview-manual/development-environment:yocto project source repositories`
    that are either pulled from during the build or established on the
    host development system prior to the build by either cloning a
    particular kernel's Git repository or by downloading and unpacking a
@@ -293,13 +293,13 @@
 
 -  *Files Accessed While using devtool:* ``devtool``, which is
    available with the Yocto Project, is the preferred method by which to
-   modify the kernel. See the ":ref:`kernel-dev/kernel-dev-intro:kernel modification workflow`" section.
+   modify the kernel. See the ":ref:`kernel-dev/intro:kernel modification workflow`" section.
 
 -  *Cloned Repository:* If you are working in the kernel all the time,
    you probably would want to set up your own local Git repository of
    the Yocto Linux kernel tree. For information on how to clone a Yocto
    Linux kernel Git repository, see the
-   ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+   ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
    section.
 
 -  *Temporary Source Files from a Build:* If you just need to make some
@@ -327,11 +327,11 @@
 
 Again, for additional information on the Yocto Project kernel's
 architecture and its branching strategy, see the
-":ref:`kernel-dev/kernel-dev-concepts-appx:yocto linux kernel architecture and branching strategies`"
+":ref:`kernel-dev/concepts-appx:yocto linux kernel architecture and branching strategies`"
 section. You can also reference the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
 and
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 sections for detailed example that modifies the kernel.
 
 Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
@@ -341,7 +341,7 @@
 most developers can ignore. For general information on kernel
 configuration including ``menuconfig``, ``defconfig`` files, and
 configuration fragments, see the
-":ref:`kernel-dev/kernel-dev-common:configuring the kernel`" section.
+":ref:`kernel-dev/common:configuring the kernel`" section.
 
 During this part of the audit phase, the contents of the final
 ``.config`` file are compared against the fragments specified by the
diff --git a/poky/documentation/kernel-dev/kernel-dev-faq.rst b/poky/documentation/kernel-dev/faq.rst
similarity index 85%
rename from poky/documentation/kernel-dev/kernel-dev-faq.rst
rename to poky/documentation/kernel-dev/faq.rst
index 424e626..c2106f8 100644
--- a/poky/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/poky/documentation/kernel-dev/faq.rst
@@ -13,21 +13,21 @@
 --------------------------------------------------
 
 Refer to the
-":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
+":ref:`kernel-dev/common:changing the configuration`"
 section for information.
 
 How do I create configuration fragments?
 ----------------------------------------
 
 A: Refer to the
-":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+":ref:`kernel-dev/common:creating configuration fragments`"
 section for information.
 
 How do I use my own Linux kernel sources?
 -----------------------------------------
 
 Refer to the
-":ref:`kernel-dev/kernel-dev-common:working with your own sources`"
+":ref:`kernel-dev/common:working with your own sources`"
 section for information.
 
 How do I install/not-install the kernel image on the rootfs?
@@ -38,7 +38,7 @@
 specify whether or not the kernel image is installed in the generated
 root filesystem, override ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base`` to include or not
 include "kernel-image". See the
-":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
 section in the
 Yocto Project Development Tasks Manual for information on how to use an
 append file to override metadata.
@@ -63,7 +63,7 @@
    MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
 
 For more information, see the
-":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section.
+":ref:`kernel-dev/common:incorporating out-of-tree modules`" section.
 
 How do I change the Linux kernel command line?
 ----------------------------------------------
diff --git a/poky/documentation/kernel-dev/kernel-dev.rst b/poky/documentation/kernel-dev/index.rst
similarity index 68%
rename from poky/documentation/kernel-dev/kernel-dev.rst
rename to poky/documentation/kernel-dev/index.rst
index 55b42ed..a8848ec 100644
--- a/poky/documentation/kernel-dev/kernel-dev.rst
+++ b/poky/documentation/kernel-dev/index.rst
@@ -10,12 +10,12 @@
    :caption: Table of Contents
    :numbered:
 
-   kernel-dev-intro
-   kernel-dev-common
-   kernel-dev-advanced
-   kernel-dev-concepts-appx
-   kernel-dev-maint-appx
-   kernel-dev-faq
+   intro
+   common
+   advanced
+   concepts-appx
+   maint-appx
+   faq
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/kernel-dev/kernel-dev-intro.rst b/poky/documentation/kernel-dev/intro.rst
similarity index 87%
rename from poky/documentation/kernel-dev/kernel-dev-intro.rst
rename to poky/documentation/kernel-dev/intro.rst
index 309c65b..c95d2f7 100644
--- a/poky/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/poky/documentation/kernel-dev/intro.rst
@@ -27,7 +27,7 @@
 align, these previous releases are updated to include the latest from
 the Long Term Support Initiative (LTSI) project. You can learn more
 about Yocto Linux kernels and LTSI in the
-":ref:`kernel-dev/kernel-dev-concepts-appx:yocto project kernel development and maintenance`" section.
+":ref:`kernel-dev/concepts-appx:yocto project kernel development and maintenance`" section.
 
 Also included is a Yocto Linux kernel development recipe
 (``linux-yocto-dev.bb``) should you want to work with the very latest in
@@ -36,7 +36,7 @@
 .. note::
 
    For more on Yocto Linux kernels, see the
-   ":ref:`kernel-dev/kernel-dev-concepts-appx:yocto project kernel development and maintenance`"
+   ":ref:`kernel-dev/concepts-appx:yocto project kernel development and maintenance`"
    section.
 
 The Yocto Project also provides a powerful set of kernel tools for
@@ -79,16 +79,16 @@
 you need some additional background, please be sure to review and
 understand the following documentation:
 
--  :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+-  :doc:`/brief-yoctoprojectqs/index` document.
 
--  :doc:`../overview-manual/overview-manual`.
+-  :doc:`/overview-manual/index`.
 
 -  :ref:`devtool
-   workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+   workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
    as described in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual.
 
--  The ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+-  The ":ref:`dev-manual/common-tasks:understanding and creating layers`"
    section in the Yocto Project Development Tasks Manual.
 
 -  The "`Kernel Modification
@@ -111,7 +111,7 @@
    :align: center
 
 1. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":doc:`../dev-manual/dev-manual-start`" section in
+   Yocto Project*: See the ":doc:`/dev-manual/start`" section in
    the Yocto Project Development Tasks Manual for options on how to get
    a build host ready to use the Yocto Project.
 
@@ -124,13 +124,13 @@
    Using ``devtool`` and the eSDK requires that you have a clean build
    of the image and that you are set up with the appropriate eSDK. For
    more information, see the
-   ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+   ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
    section.
 
    Using traditional kernel development requires that you have the
    kernel source available in an isolated local Git repository. For more
    information, see the
-   ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
+   ":ref:`kernel-dev/common:getting ready for traditional kernel development`"
    section.
 
 3. *Make Changes to the Kernel Source Code if applicable:* Modifying the
@@ -138,17 +138,17 @@
    if you have to do this, you make the changes to the files in the
    eSDK's Build Directory if you are using ``devtool``. For more
    information, see the
-   ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+   ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
    section.
 
    If you are using traditional kernel development, you edit the source
    files in the kernel's local Git repository. For more information, see the
-   ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+   ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
    section.
 
 4. *Make Kernel Configuration Changes if Applicable:* If your situation
    calls for changing the kernel's configuration, you can use
-   :ref:`menuconfig <kernel-dev/kernel-dev-common:using \`\`menuconfig\`\`>`,
+   :ref:`menuconfig <kernel-dev/common:using \`\`menuconfig\`\`>`,
    which allows you to
    interactively develop and test the configuration changes you are
    making to the kernel. Saving changes you make with ``menuconfig``
@@ -165,7 +165,7 @@
    ``menuconfig`` and you have saved them, you can directly compare the
    resulting ``.config`` file against an existing original and gather
    those changes into a
-   :ref:`configuration fragment file <kernel-dev/kernel-dev-common:creating configuration fragments>` to be
+   :ref:`configuration fragment file <kernel-dev/common:creating configuration fragments>` to be
    referenced from within the kernel's ``.bbappend`` file.
 
    Additionally, if you are working in a BSP layer and need to modify
diff --git a/poky/documentation/kernel-dev/kernel-dev-maint-appx.rst b/poky/documentation/kernel-dev/maint-appx.rst
similarity index 97%
rename from poky/documentation/kernel-dev/kernel-dev-maint-appx.rst
rename to poky/documentation/kernel-dev/maint-appx.rst
index 69f6806..89f4b43 100644
--- a/poky/documentation/kernel-dev/kernel-dev-maint-appx.rst
+++ b/poky/documentation/kernel-dev/maint-appx.rst
@@ -37,7 +37,7 @@
 For more information on
 how to set up a local Git repository of the Yocto Project Linux kernel
 files, see the
-":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
 section.
 
 Once you have cloned the kernel Git repository and the cache of Metadata
@@ -103,7 +103,7 @@
    located by searching these system directories:
 
    -  The in-tree kernel-cache directories, which are located in the
-      :yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache/tree/bsp>`
+      :yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/bsp>`
       repository organized under the "Yocto Linux Kernel" heading in the
       :yocto_git:`Yocto Project Source Repositories <>`.
 
@@ -167,7 +167,7 @@
       The end result is a branched, clean history tree that makes up the
       kernel for a given release. You can see the script (``kgit-scc``)
       responsible for this in the
-      :yocto_git:`yocto-kernel-tools </cgit.cgi/yocto-kernel-tools/tree/tools>`
+      :yocto_git:`yocto-kernel-tools </yocto-kernel-tools/tree/tools>`
       repository.
 
    -  The steps used to construct the full kernel tree are the same
diff --git a/poky/documentation/overview-manual/overview-manual-concepts.rst b/poky/documentation/overview-manual/concepts.rst
similarity index 96%
rename from poky/documentation/overview-manual/overview-manual-concepts.rst
rename to poky/documentation/overview-manual/concepts.rst
index 736fd95..8fbbabb 100644
--- a/poky/documentation/overview-manual/overview-manual-concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -34,17 +34,15 @@
 
 BitBake knows how to combine multiple data sources together and refers
 to each data source as a layer. For information on layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section of the Yocto Project Development Tasks Manual.
 
 Following are some brief details on these core components. For
 additional information on how these components interact during a build,
 see the
-":ref:`overview-manual/overview-manual-concepts:openembedded build system concepts`"
+":ref:`overview-manual/concepts:openembedded build system concepts`"
 section.
 
-.. _usingpoky-components-bitbake:
-
 BitBake
 -------
 
@@ -78,7 +76,7 @@
 selected by the distribution configuration. You can get more details
 about how BitBake chooses between different target versions and
 providers in the
-":ref:`Preferences <bitbake:bb-bitbake-preferences>`" section
+":ref:`Preferences <bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences>`" section
 of the BitBake User Manual.
 
 BitBake also tries to execute any dependent tasks first. So for example,
@@ -92,8 +90,6 @@
 remade. However, when you use this option other dependencies can still
 be processed.
 
-.. _overview-components-recipes:
-
 Recipes
 -------
 
@@ -109,8 +105,6 @@
 build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
 using the term "package" when referring to recipes.
 
-.. _overview-components-classes:
-
 Classes
 -------
 
@@ -118,12 +112,10 @@
 between recipes files. An example is the
 :ref:`autotools <ref-classes-autotools>` class,
 which contains common settings for any application that Autotools uses.
-The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
+The ":ref:`ref-manual/classes:Classes`" chapter in the
 Yocto Project Reference Manual provides details about classes and how to
 use them.
 
-.. _overview-components-configurations:
-
 Configurations
 --------------
 
@@ -135,8 +127,6 @@
 ``conf/local.conf``, which is found in the :term:`Build Directory`.
 
 
-.. _overview-layers:
-
 Layers
 ======
 
@@ -163,11 +153,9 @@
 during builds on where to find types of metadata. You can find
 procedures and learn about tools (i.e. ``bitbake-layers``) for creating
 layers suitable for the Yocto Project in the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section of the Yocto Project Development Tasks Manual.
 
-.. _openembedded-build-system-build-concepts:
-
 OpenEmbedded Build System Concepts
 ==================================
 
@@ -285,7 +273,7 @@
 build environment. Here is a list of a few. To see the default
 configurations in a ``local.conf`` file created by the build environment
 script, see the
-:yocto_git:`local.conf.sample </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample>`
+:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/local.conf.sample>`
 in the ``meta-poky`` layer:
 
 -  *Target Machine Selection:* Controlled by the
@@ -329,7 +317,7 @@
 layers minimally needed by the build system. However, you must manually
 add any custom layers you have created. You can find more information on
 working with the ``bblayers.conf`` file in the
-":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`"
+":ref:`dev-manual/common-tasks:enabling your layer`"
 section in the Yocto Project Development Tasks Manual.
 
 The files ``site.conf`` and ``auto.conf`` are not created by the
@@ -405,17 +393,17 @@
    configurations. This type of information is specific to a particular
    target architecture. A good example of a BSP layer from the `Poky
    Reference Distribution <#gs-reference-distribution-poky>`__ is the
-   :yocto_git:`meta-yocto-bsp </cgit/cgit.cgi/poky/tree/meta-yocto-bsp>`
+   :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
    layer.
 
 -  *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in
    the following figure) providing top-level or general policies for the
    images or SDKs being built for a particular distribution. For
    example, in the Poky Reference Distribution the distro layer is the
-   :yocto_git:`meta-poky </cgit/cgit.cgi/poky/tree/meta-poky>`
+   :yocto_git:`meta-poky </poky/tree/meta-poky>`
    layer. Within the distro layer is a ``conf/distro`` directory that
    contains distro configuration files (e.g.
-   :yocto_git:`poky.conf </cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf>`
+   :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
    that contain many policy configurations for the Poky distribution.
 
 The following figure shows an expanded representation of these three
@@ -430,7 +418,7 @@
 distributed, a configuration directory, and recipe directories. You can
 learn about the general structure for layers used with the Yocto Project
 in the
-":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+":ref:`dev-manual/common-tasks:creating your own layer`"
 section in the
 Yocto Project Development Tasks Manual. For a general discussion on
 layers and the many layers from which you can draw, see the
@@ -439,9 +427,8 @@
 manual.
 
 If you explored the previous links, you discovered some areas where many
-layers that work with the Yocto Project exist. The `Source
-Repositories <http://git.yoctoproject.org/>`__ also shows layers
-categorized under "Yocto Metadata Layers."
+layers that work with the Yocto Project exist. The :yocto_git:`Source
+Repositories <>` also shows layers categorized under "Yocto Metadata Layers."
 
 .. note::
 
@@ -469,7 +456,7 @@
    can be shared among recipes in the distribution. When your recipes
    inherit a class, they take on the settings and functions for that
    class. You can read more about class files in the
-   ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
+   ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
    Reference Manual.
 
 -  *conf:* This area holds configuration files for the layer
@@ -494,7 +481,7 @@
 hardware. Everything in this layer is specific to the machine for which
 you are building the image or the SDK. A common structure or form is
 defined for BSP layers. You can learn more about this structure in the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
 
 .. note::
 
@@ -527,8 +514,6 @@
 This layer contains any recipes, append files, and patches, that your
 project needs.
 
-.. _sources-dev-environment:
-
 Sources
 -------
 
@@ -601,13 +586,11 @@
 or a recipe's append file to override or set the recipe to point to the
 local directory on your disk to pull in the whole source tree.
 
-.. _scms:
-
 Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Another place from which the build system can get source files is with
-:ref:`fetchers <bitbake:bb-fetchers>` employing various Source
+:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` employing various Source
 Control Managers (SCMs) such as Git or Subversion. In such cases, a
 repository is cloned or checked out. The
 :ref:`ref-tasks-fetch` task inside
@@ -644,8 +627,6 @@
 alternative location for source code should the primary site not be
 functioning for some reason or another.
 
-.. _package-feeds-dev-environment:
-
 Package Feeds
 -------------
 
@@ -709,8 +690,6 @@
 ``build/tmp/deploy/ipk/i586``, while packages for the qemux86
 architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
 
-.. _bitbake-dev-environment:
-
 BitBake Tool
 ------------
 
@@ -727,8 +706,6 @@
    BitBake User Manual
    for reference material on BitBake.
 
-.. _source-fetching-dev-environment:
-
 Source Fetching
 ~~~~~~~~~~~~~~~
 
@@ -819,8 +796,6 @@
    what the OpenEmbedded build system is using as a build target (e.g.
    general architecture, a build host, an SDK, or a specific machine).
 
-.. _patching-dev-environment:
-
 Patching
 ~~~~~~~~
 
@@ -852,17 +827,15 @@
 "`Source Fetching <#source-fetching-dev-environment>`__" section. For
 more information on how to create patches and how the build system
 processes patches, see the
-":ref:`dev-manual/dev-manual-common-tasks:patching code`"
+":ref:`dev-manual/common-tasks:patching code`"
 section in the
 Yocto Project Development Tasks Manual. You can also see the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
+":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (SDK) manual and the
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 section in the Yocto Project Linux Kernel Development Manual.
 
-.. _configuration-compilation-and-staging-dev-environment:
-
 Configuration, Compilation, and Staging
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -905,7 +878,7 @@
    variables. For information on how this variable works within that
    class, see the
    :ref:`autotools <ref-classes-autotools>` class
-   :yocto_git:`here </cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass>`.
+   :yocto_git:`here </poky/tree/meta/classes/autotools.bbclass>`.
 
 -  *do_compile*: Once a configuration task has been satisfied,
    BitBake compiles the source using the
@@ -922,8 +895,6 @@
    variable. Packaging occurs later using files from this holding
    directory.
 
-.. _package-splitting-dev-environment:
-
 Package Splitting
 ~~~~~~~~~~~~~~~~~
 
@@ -985,7 +956,7 @@
 files that go into each package in
 :term:`PACKAGES`. If you want
 details on how this is accomplished, you can look at
-:yocto_git:`package.bbclass </cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`.
+:yocto_git:`package.bbclass </poky/tree/meta/classes/package.bbclass>`.
 
 Depending on the type of packages being created (RPM, DEB, or IPK), the
 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
@@ -1004,8 +975,6 @@
    functionality is highly distribution-specific and thus is not
    provided out of the box.
 
-.. _image-generation-dev-environment:
-
 Image Generation
 ~~~~~~~~~~~~~~~~
 
@@ -1060,7 +1029,7 @@
 of the packages are run. Any scripts that fail to run on the build host
 are run on the target when the target system is first booted. If you are
 using a 
-:ref:`read-only root filesystem <dev-manual/dev-manual-common-tasks:creating a read-only root filesystem>`,
+:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
 all the post installation scripts must succeed on the build host during
 the package installation phase since the root filesystem on the target
 is read-only.
@@ -1127,8 +1096,6 @@
    Pseudo. Running under Pseudo ensures that the files in the root filesystem
    have correct ownership.
 
-.. _sdk-generation-dev-environment:
-
 SDK Generation
 ~~~~~~~~~~~~~~
 
@@ -1142,10 +1109,10 @@
 .. note::
 
    For more information on the cross-development toolchain generation,
-   see the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+   see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
    section. For information on advantages gained when building a
    cross-development toolchain using the do_populate_sdk task, see the
-   ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in
+   ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
    the Yocto Project Application Development and the Extensible Software
    Development Kit (eSDK) manual.
 
@@ -1225,7 +1192,7 @@
 also always be considered out of date, which might not be what you want.
 
 For details on how to view information about a task's signature, see the
-":ref:`dev-manual/dev-manual-common-tasks:viewing task variable dependencies`"
+":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
 section in the Yocto Project Development Tasks Manual.
 
 Setscene Tasks and Shared State
@@ -1303,8 +1270,6 @@
 needs to be followed, and whether for any given relationship the
 function needs to be passed. The function returns a True or False value.
 
-.. _images-dev-environment:
-
 Images
 ------
 
@@ -1320,7 +1285,7 @@
 .. note::
 
    For a list of example images that the Yocto Project provides, see the
-   ":doc:`../ref-manual/ref-images`" chapter in the Yocto Project Reference
+   ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
    Manual.
 
 The build process writes images out to the :term:`Build Directory`
@@ -1363,8 +1328,6 @@
    These links might be useful for external scripts that need to obtain
    the latest version of each file.
 
-.. _sdk-dev-environment:
-
 Application Development SDK
 ---------------------------
 
@@ -1403,7 +1366,7 @@
       section.
 
    -  For information on setting up a cross-development environment, see
-      the :doc:`../sdk-manual/sdk-manual` manual.
+      the :doc:`/sdk-manual/index` manual.
 
 All the output files for an SDK are written to the ``deploy/sdk`` folder
 inside the :term:`Build Directory` as
@@ -1480,10 +1443,10 @@
 ======================================
 
 The Yocto Project does most of the work for you when it comes to
-creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This
+creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
 section provides some technical background on how cross-development
 toolchains are created and used. For more information on toolchains, you
-can also see the :doc:`../sdk-manual/sdk-manual` manual.
+can also see the :doc:`/sdk-manual/index` manual.
 
 In the Yocto Project development environment, cross-development
 toolchains are used to build images and applications that run on the
@@ -1610,7 +1573,7 @@
 
    For information on advantages gained when building a
    cross-development toolchain installer, see the
-   ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" appendix
+   ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
    in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual.
 
@@ -1663,22 +1626,20 @@
       the shared state packages. Consequently, considerations exist that
       affect maintaining shared state feeds. For information on how the
       build system works with packages and can track incrementing ``PR``
-      information, see the ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+      information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
       section in the Yocto Project Development Tasks Manual.
 
    -  The code in the build system that supports incremental builds is
       not simple code. For techniques that help you work around issues
       related to shared state code, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:viewing metadata used to create the input signature of a shared state task`"
+      ":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared state task`"
       and
-      ":ref:`dev-manual/dev-manual-common-tasks:invalidating shared state to force a task to run`"
+      ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
       sections both in the Yocto Project Development Tasks Manual.
 
 The rest of this section goes into detail about the overall incremental
 build architecture, the checksums (signatures), and shared state.
 
-.. _concepts-overall-architecture:
-
 Overall Architecture
 --------------------
 
@@ -1697,8 +1658,6 @@
 users to easily add new tasks in layers or as external recipes without
 touching the packaged-staging core.
 
-.. _overview-checksums:
-
 Checksums (Signatures)
 ----------------------
 
@@ -1949,7 +1908,7 @@
    extra metadata to the `stamp
    file <#stamp-files-and-the-rerunning-of-tasks>`__. In this case, the
    metadata makes the task specific to a machine's architecture. See
-   ":ref:`bitbake:ref-bitbake-tasklist`"
+   ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
    section in the BitBake User Manual for more information on the
    ``stamp-extra-info`` flag.
 
diff --git a/poky/documentation/overview-manual/overview-manual-development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
similarity index 94%
rename from poky/documentation/overview-manual/overview-manual-development-environment.rst
rename to poky/documentation/overview-manual/development-environment.rst
index 4bedd6d..9a2997d 100644
--- a/poky/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -45,8 +45,6 @@
 Community
 `here <https://www.kernel.org/doc/html/latest/process/index.html>`__.
 
-.. _gs-the-development-host:
-
 The Development Host
 ====================
 
@@ -68,7 +66,7 @@
 environment that is similar to what you see when using a Linux-based
 development host. For the steps needed to set up a system using CROPS,
 see the
-":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
 section in
 the Yocto Project Development Tasks Manual.
 
@@ -79,7 +77,7 @@
 also need to be sure that the correct set of host packages are installed
 that allow development using the Yocto Project. For the steps needed to
 set up a development host that runs Linux, see the
-":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+":ref:`dev-manual/start:setting up a native linux host`"
 section in the Yocto Project Development Tasks Manual.
 
 Once your development host is set up to use the Yocto Project, several
@@ -96,7 +94,7 @@
    through your Linux distribution and the Yocto Project.
 
    For a general flow of the build procedures, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:building a simple image`"
+   ":ref:`dev-manual/common-tasks:building a simple image`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Board Support Package (BSP) Development:* Development of BSPs
@@ -105,7 +103,7 @@
    hardware. To development BSPs, you need to take some additional steps
    beyond what was described in setting up a development host.
 
-   The :doc:`../bsp-guide/bsp-guide` provides BSP-related development
+   The :doc:`/bsp-guide/index` provides BSP-related development
    information. For specifics on development host preparation, see the
    ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`"
    section in the Yocto Project Board Support Package (BSP) Developer's
@@ -116,10 +114,10 @@
    using ``devtool`` makes kernel development quicker by reducing
    iteration cycle times.
 
-   The :doc:`../kernel-dev/kernel-dev` provides kernel-related
+   The :doc:`/kernel-dev/index` provides kernel-related
    development information. For specifics on development host
    preparation, see the
-   ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+   ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
    section in the Yocto Project Linux Kernel Development Manual.
 
 -  *Using Toaster:* The other Yocto Project development method that
@@ -132,9 +130,7 @@
 
    For steps that show you how to set up your development host to use
    Toaster and on how to use Toaster in general, see the
-   :doc:`../toaster-manual/toaster-manual`.
-
-.. _yocto-project-repositories:
+   :doc:`/toaster-manual/index`.
 
 Yocto Project Source Repositories
 =================================
@@ -182,7 +178,7 @@
       :align: center
 
    For steps on how to view and access these upstream Git repositories,
-   see the ":ref:`dev-manual/dev-manual-start:accessing source repositories`"
+   see the ":ref:`dev-manual/start:accessing source repositories`"
    Section in the Yocto Project Development Tasks Manual.
 
 -  :yocto_dl:`Index of /releases: </releases>` This is an index
@@ -196,7 +192,7 @@
       :align: center
 
    For steps on how to view and access these files, see the
-   ":ref:`dev-manual/dev-manual-start:accessing index of releases`"
+   ":ref:`dev-manual/start:accessing index of releases`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *"DOWNLOADS" page for the* :yocto_home:`Yocto Project Website <>` *:*
@@ -211,11 +207,9 @@
       :align: center
 
    For steps on how to use the "DOWNLOADS" page, see the
-   ":ref:`dev-manual/dev-manual-start:using the downloads page`"
+   ":ref:`dev-manual/start:using the downloads page`"
    section in the Yocto Project Development Tasks Manual.
 
-.. _gs-git-workflows-and-the-yocto-project:
-
 Git Workflows and the Yocto Project
 ===================================
 
@@ -248,7 +242,7 @@
 
    For information on finding out who is responsible for (maintains) a
    particular area of code in the Yocto Project, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+   ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
    section of the Yocto Project Development Tasks Manual.
 
 The Yocto Project ``poky`` Git repository also has an upstream
@@ -280,7 +274,7 @@
 maintainer include them into an upstream branch. This process is called
 "submitting a patch" or "submitting a change." For information on
 submitting patches and changes, see the
-":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
 section in the Yocto Project Development Tasks Manual.
 
 In summary, a single point of entry exists for changes into a "master"
@@ -347,7 +341,7 @@
    the ``scripts`` folder of the
    :term:`Source Directory`. For information
    on how to use these scripts, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull`"
+   ":ref:`dev-manual/common-tasks:using scripts to push a change upstream and request a pull`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Patch Workflow:* This workflow allows you to notify the maintainer
@@ -356,7 +350,7 @@
    this type of change, you format the patch and then send the email
    using the Git commands ``git format-patch`` and ``git send-email``.
    For information on how to use these scripts, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+   ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
    section in the Yocto Project Development Tasks Manual.
 
 Git
@@ -382,7 +376,7 @@
       page, see http://git-scm.com/download.
 
    -  For information beyond the introductory nature in this section,
-      see the ":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+      see the ":ref:`dev-manual/start:locating yocto project source files`"
       section in the Yocto Project Development Tasks Manual.
 
 Repositories, Tags, and Branches
@@ -414,7 +408,7 @@
 an identical copy of the repository on your development system. Once you
 have a local copy of a repository, you can take steps to develop
 locally. For examples on how to clone Git repositories, see the
-":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+":ref:`dev-manual/start:locating yocto project source files`"
 section in the Yocto Project Development Tasks Manual.
 
 It is important to understand that Git tracks content change and not
@@ -422,7 +416,7 @@
 For example, the ``poky`` repository has several branches that include
 the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many
 branches for past Yocto Project releases. You can see all the branches
-by going to https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the
+by going to :yocto_git:`/poky/` and clicking on the
 ``[...]`` link beneath the "Branch" heading.
 
 Each of these branches represents a specific area of development. The
@@ -467,9 +461,8 @@
 Git uses "tags" to mark specific changes in a repository branch
 structure. Typically, a tag is used to mark a special point such as the
 final change (or commit) before a project is released. You can see the
-tags used with the ``poky`` Git repository by going to
-https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the ``[...]`` link
-beneath the "Tag" heading.
+tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/`
+and clicking on the ``[...]`` link beneath the "Tag" heading.
 
 Some key tags for the ``poky`` repository are ``jethro-14.0.3``,
 ``morty-16.0.1``, ``pyro-17.0.0``, and
@@ -668,5 +661,5 @@
 For information that can help you maintain compliance with various open
 source licensing during the lifecycle of a product created using the
 Yocto Project, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
diff --git a/poky/documentation/overview-manual/overview-manual.rst b/poky/documentation/overview-manual/index.rst
similarity index 69%
rename from poky/documentation/overview-manual/overview-manual.rst
rename to poky/documentation/overview-manual/index.rst
index f20b20e..123aed9b 100644
--- a/poky/documentation/overview-manual/overview-manual.rst
+++ b/poky/documentation/overview-manual/index.rst
@@ -10,10 +10,10 @@
    :caption: Table of Contents
    :numbered:
 
-   overview-manual-intro
-   overview-manual-yp-intro
-   overview-manual-development-environment
-   overview-manual-concepts
+   intro
+   yp-intro
+   development-environment
+   concepts
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/overview-manual/overview-manual-intro.rst b/poky/documentation/overview-manual/intro.rst
similarity index 86%
rename from poky/documentation/overview-manual/overview-manual-intro.rst
rename to poky/documentation/overview-manual/intro.rst
index 8885eb8..bd247dd 100644
--- a/poky/documentation/overview-manual/overview-manual-intro.rst
+++ b/poky/documentation/overview-manual/intro.rst
@@ -4,8 +4,6 @@
 The Yocto Project Overview and Concepts Manual
 **********************************************
 
-.. _overview-manual-welcome:
-
 Welcome
 =======
 
@@ -30,7 +28,7 @@
    Yocto Project source repositories, workflows using Git and the Yocto
    Project, a Git primer, and information about licensing.
 
--  :doc:`overview-manual-concepts` *:* This
+-  :doc:`/overview-manual/concepts` *:* This
    chapter presents various concepts regarding the Yocto Project. You
    can find conceptual information about components, development,
    cross-toolchains, and so forth.
@@ -39,17 +37,17 @@
 
 -  *Step-by-step Instructions for Development Tasks:* Instructional
    procedures reside in other manuals within the Yocto Project
-   documentation set. For example, the :doc:`../dev-manual/dev-manual`
+   documentation set. For example, the :doc:`/dev-manual/index`
    provides examples on how to perform
    various development tasks. As another example, the 
-   :doc:`../sdk-manual/sdk-manual` manual contains detailed
+   :doc:`/sdk-manual/index` manual contains detailed
    instructions on how to install an SDK, which is used to develop
    applications for target hardware.
 
 -  *Reference Material:* This type of material resides in an appropriate
    reference manual. For example, system variables are documented in the
-   :doc:`../ref-manual/ref-manual`. As another
-   example, the :doc:`../bsp-guide/bsp-guide` contains reference information on
+   :doc:`/ref-manual/index`. As another
+   example, the :doc:`/bsp-guide/index` contains reference information on
    BSPs.
 
 -  *Detailed Public Information Not Specific to the Yocto Project:* For
@@ -57,8 +55,6 @@
    Manager Git is better covered with Internet searches and official Git
    Documentation than through the Yocto Project documentation.
 
-.. _overview-manual-other-information:
-
 Other Information
 =================
 
@@ -67,7 +63,7 @@
 additional introductory information on the Yocto Project, see the
 :yocto_home:`Yocto Project Website <>`. If you want to build an image
 with no knowledge of Yocto Project as a way of quickly testing it out,
-see the :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+see the :doc:`/brief-yoctoprojectqs/index` document.
 For a comprehensive list of links and other documentation, see the
 ":ref:`Links and Related
 Documentation <resources-links-and-related-documentation>`"
diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
similarity index 94%
rename from poky/documentation/overview-manual/overview-manual-yp-intro.rst
rename to poky/documentation/overview-manual/yp-intro.rst
index 9073582..66a88c9 100644
--- a/poky/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -35,8 +35,6 @@
 The remainder of this section overviews advantages and challenges tied
 to the Yocto Project.
 
-.. _gs-features:
-
 Features
 --------
 
@@ -113,7 +111,7 @@
    development.
 
 -  *Releases According to a Strict Schedule:* Major releases occur on a
-   :doc:`six-month cycle <../ref-manual/ref-release-process>`
+   :doc:`six-month cycle </ref-manual/release-process>`
    predictably in October and April. The most recent two releases
    support point releases to address common vulnerabilities and
    exposures. This predictability is crucial for projects based on the
@@ -132,12 +130,10 @@
    arbitrarily include packages.
 
 -  *License Manifest:* The Yocto Project provides a :ref:`license
-   manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>`
+   manifest <dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle>`
    for review by people who need to track the use of open source
    licenses (e.g. legal teams).
 
-.. _gs-challenges:
-
 Challenges
 ----------
 
@@ -232,7 +228,7 @@
 
    -  Layers support the inclusion of technologies, hardware components,
       and software components. The :ref:`Yocto Project
-      Compatible <dev-manual/dev-manual-common-tasks:making sure your layer is compatible with yocto project>`
+      Compatible <dev-manual/common-tasks:making sure your layer is compatible with yocto project>`
       designation provides a minimum level of standardization that
       contributes to a strong ecosystem. "YP Compatible" is applied to
       appropriate products and software components such as BSPs, other
@@ -255,7 +251,7 @@
 .. note::
 
    For general information on BSP layer structure, see the
-   :doc:`../bsp-guide/bsp-guide`
+   :doc:`/bsp-guide/index`
    .
 
 The :term:`Source Directory`
@@ -271,15 +267,14 @@
    , but it is a commonly accepted standard in the Yocto Project
    community.
 
-For example, if you were to examine the `tree
-view <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/>`__ of the
-``poky`` repository, you will see several layers: ``meta``,
+For example, if you were to examine the :yocto_git:`tree view </poky/tree/>`
+of the ``poky`` repository, you will see several layers: ``meta``,
 ``meta-skeleton``, ``meta-selftest``, ``meta-poky``, and
 ``meta-yocto-bsp``. Each of these repositories represents a distinct
 layer.
 
 For procedures on how to create layers, see the 
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section in the Yocto Project Development Tasks Manual.
 
 Components and Tools
@@ -296,8 +291,6 @@
 This section provides brief overviews of the components and tools
 associated with the Yocto Project.
 
-.. _gs-development-tools:
-
 Development Tools
 -----------------
 
@@ -334,7 +327,7 @@
    You can read about the ``devtool`` workflow in the Yocto Project
    Application Development and Extensible Software Development Kit
    (eSDK) Manual in the 
-   ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+   ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
    section.
 
 -  *Extensible Software Development Kit (eSDK):* The eSDK provides a
@@ -346,14 +339,12 @@
    experience supplemented with the powerful set of ``devtool`` commands
    tailored for the Yocto Project environment.
 
-   For information on the eSDK, see the :doc:`../sdk-manual/sdk-manual` Manual.
+   For information on the eSDK, see the :doc:`/sdk-manual/index` Manual.
 
 -  *Toaster:* Toaster is a web interface to the Yocto Project
    OpenEmbedded build system. Toaster allows you to configure, run, and
    view information about builds. For information on Toaster, see the
-   :doc:`../toaster-manual/toaster-manual`.
-
-.. _gs-production-tools:
+   :doc:`/toaster-manual/index`.
 
 Production Tools
 ----------------
@@ -366,7 +357,7 @@
    (BitBake and
    OE-Core) automatically generates upgrades for recipes that are based
    on new versions of the recipes published upstream. See
-   :ref:`dev-manual/dev-manual-common-tasks:using the auto upgrade helper (auh)`
+   :ref:`dev-manual/common-tasks:using the auto upgrade helper (auh)`
    for how to set it up.
 
 -  *Recipe Reporting System:* The Recipe Reporting System tracks recipe
@@ -401,7 +392,7 @@
    benefit of the development community.
 
    You can learn more about the AutoBuilder used by the Yocto Project
-   Autobuilder :doc:`here <../test-manual/test-manual-understand-autobuilder>`.
+   Autobuilder :doc:`here </test-manual/understand-autobuilder>`.
 
 -  *Cross-Prelink:* Prelinking is the process of pre-computing the load
    addresses and link tables generated by the dynamic linker as compared
@@ -450,8 +441,6 @@
    You can read more about Pseudo in the "`Fakeroot and
    Pseudo <#fakeroot-and-pseudo>`__" section.
 
-.. _gs-openembedded-build-system:
-
 Open-Embedded Build System Components
 -------------------------------------
 
@@ -477,7 +466,7 @@
    OpenEmbedded-derived systems, which includes the Yocto Project. The
    Yocto Project and the OpenEmbedded Project both maintain the
    OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto
-   Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta>`.
+   Project :yocto_git:`Source Repositories </poky/tree/meta>`.
 
    Historically, the Yocto Project integrated the OE-Core metadata
    throughout the Yocto Project source repository reference system
@@ -496,8 +485,6 @@
    components such as BitBake, OE-Core, script "glue", and documentation
    for its build system.
 
-.. _gs-reference-distribution-poky:
-
 Reference Distribution (Poky)
 -----------------------------
 
@@ -520,8 +507,6 @@
 You can read more about Poky in the "`Reference Embedded Distribution
 (Poky) <#reference-embedded-distribution>`__" section.
 
-.. _gs-packages-for-finished-targets:
-
 Packages for Finished Targets
 -----------------------------
 
@@ -560,8 +545,6 @@
    You can find the opkg source in the Yocto Project
    :yocto_git:`Source Repositories <>`.
 
-.. _gs-archived-components:
-
 Archived Components
 -------------------
 
@@ -588,8 +571,6 @@
    using the Yocto Project on a system not native to Linux is with
    `CROPS <#gs-crops-overview>`__.
 
-.. _gs-development-methods:
-
 Development Methods
 ===================
 
@@ -608,7 +589,7 @@
 .. note::
 
    For additional detail about the Yocto Project development
-   environment, see the ":doc:`overview-manual-development-environment`"
+   environment, see the ":doc:`/overview-manual/development-environment`"
    chapter.
 
 -  *Native Linux Host:* By far the best option for a Build Host. A
@@ -620,7 +601,7 @@
 
    For information on how to set up a Build Host on a system running
    Linux as its native operating system, see the 
-   ":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+   ":ref:`dev-manual/start:setting up a native linux host`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *CROss PlatformS (CROPS):* Typically, you use
@@ -640,7 +621,7 @@
    system natively running Linux.
 
    For information on how to set up a Build Host with CROPS, see the
-   ":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+   ":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem
@@ -657,7 +638,7 @@
    virtualization technology.
 
    For information on how to set up a Build Host with WSLv2, see the
-   ":ref:`dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`"
+   ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Toaster:* Regardless of what your Build Host is running, you can use
@@ -669,9 +650,7 @@
    configure and start builds on multiple remote build servers.
 
    For information about and how to use Toaster, see the 
-   :doc:`../toaster-manual/toaster-manual`.
-
-.. _reference-embedded-distribution:
+   :doc:`/toaster-manual/index`.
 
 Reference Embedded Distribution (Poky)
 ======================================
@@ -691,13 +670,13 @@
 found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation
 provided all together and known to work well together. You can view
 these items that make up the Poky repository in the
-:yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/>`.
+:yocto_git:`Source Repositories </poky/tree/>`.
 
 .. note::
 
    If you are interested in all the contents of the
    poky
-   Git repository, see the ":ref:`ref-manual/ref-structure:top-level core components`"
+   Git repository, see the ":ref:`ref-manual/structure:top-level core components`"
    section in the Yocto Project Reference Manual.
 
 The following figure illustrates what generally comprises Poky:
@@ -741,7 +720,7 @@
 own version. Major releases occur at the same time major releases (point
 releases) occur for the Yocto Project, which are typically in the Spring
 and Fall. For more information on the Yocto Project release schedule and
-cadence, see the ":doc:`../ref-manual/ref-release-process`" chapter in the
+cadence, see the ":doc:`/ref-manual/release-process`" chapter in the
 Yocto Project Reference Manual.
 
 Much has been said about Poky being a "default configuration". A default
@@ -776,8 +755,6 @@
 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`"
 section in the BitBake User's Manual.
 
-.. _openembedded-build-system-workflow:
-
 The OpenEmbedded Build System Workflow
 ======================================
 
@@ -821,7 +798,7 @@
 
 It helps to understand some basic fundamental terms when learning the
 Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
-Terms <../ref-manual/ref-terms>`" section of the Yocto Project
+Terms </ref-manual/terms>`" section of the Yocto Project
 Reference Manual, this section provides the definitions of some terms
 helpful for getting started:
 
@@ -835,7 +812,7 @@
    application developers. This eSDK allows developers to incorporate
    their library and programming changes back into the image to make
    their code available to other application developers. For information
-   on the eSDK, see the :doc:`../sdk-manual/sdk-manual` manual.
+   on the eSDK, see the :doc:`/sdk-manual/index` manual.
 
 -  *Layer:* A collection of related recipes. Layers allow you to
    consolidate related metadata to customize your build. Layers also
@@ -847,7 +824,7 @@
    Project.
 
    For more detailed information on layers, see the 
-   ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+   ":ref:`dev-manual/common-tasks:understanding and creating layers`"
    section in the Yocto Project Development Tasks Manual. For a
    discussion specifically on BSP Layers, see the 
    ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto
@@ -892,8 +869,7 @@
    set of recipes.
 
    You can see the Metadata in the ``meta`` directory of the Yocto
-   Project `Source
-   Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__.
+   Project :yocto_git:`Source Repositories <>`.
 
 -  *Packages:* In the context of the Yocto Project, this term refers to
    a recipe's packaged output produced by BitBake (i.e. a "baked
@@ -903,7 +879,7 @@
 
    It is worth noting that the term "package" can, in general, have
    subtle meanings. For example, the packages referred to in the
-   ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+   ":ref:`ref-manual/system-requirements:required packages for the build host`"
    section in the Yocto Project Reference Manual are compiled binaries
    that, when installed, add functionality to your Linux distribution.
 
diff --git a/poky/documentation/poky.yaml b/poky/documentation/poky.yaml
index 57da0a7..c1340c2 100644
--- a/poky/documentation/poky.yaml
+++ b/poky/documentation/poky.yaml
@@ -4,7 +4,7 @@
 DISTRO_NAME_NO_CAP_MINUS_ONE : "dunfell"
 DISTRO_NAME_NO_CAP_LTS : "dunfell"
 YOCTO_DOC_VERSION : "3.2"
-YOCTO_DOC_VERSION_MINUS_ONE : "3.1.3"
+YOCTO_DOC_VERSION_MINUS_ONE : "3.1.4"
 DISTRO_REL_TAG : "yocto-3.2"
 POKYVERSION : "24.0.0"
 YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;"
diff --git a/poky/documentation/profile-manual/profile-manual-arch.rst b/poky/documentation/profile-manual/arch.rst
similarity index 100%
rename from poky/documentation/profile-manual/profile-manual-arch.rst
rename to poky/documentation/profile-manual/arch.rst
diff --git a/poky/documentation/profile-manual/profile-manual-examples.rst b/poky/documentation/profile-manual/examples.rst
similarity index 100%
rename from poky/documentation/profile-manual/profile-manual-examples.rst
rename to poky/documentation/profile-manual/examples.rst
diff --git a/poky/documentation/profile-manual/profile-manual.rst b/poky/documentation/profile-manual/index.rst
similarity index 73%
rename from poky/documentation/profile-manual/profile-manual.rst
rename to poky/documentation/profile-manual/index.rst
index 5ec5b9e..6e54133 100644
--- a/poky/documentation/profile-manual/profile-manual.rst
+++ b/poky/documentation/profile-manual/index.rst
@@ -10,10 +10,10 @@
    :caption: Table of Contents
    :numbered:
 
-   profile-manual-intro
-   profile-manual-arch
-   profile-manual-usage
-   profile-manual-examples
+   intro
+   arch
+   usage
+   examples
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/profile-manual/profile-manual-intro.rst b/poky/documentation/profile-manual/intro.rst
similarity index 100%
rename from poky/documentation/profile-manual/profile-manual-intro.rst
rename to poky/documentation/profile-manual/intro.rst
diff --git a/poky/documentation/profile-manual/profile-manual-usage.rst b/poky/documentation/profile-manual/usage.rst
similarity index 99%
rename from poky/documentation/profile-manual/profile-manual-usage.rst
rename to poky/documentation/profile-manual/usage.rst
index cc403a5..418f4e9 100644
--- a/poky/documentation/profile-manual/profile-manual-usage.rst
+++ b/poky/documentation/profile-manual/usage.rst
@@ -45,7 +45,7 @@
 ----------
 
 For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
 
 In particular, you'll get the most mileage out of perf if you profile an
 image built with the following in your ``local.conf`` file: ::
@@ -1183,7 +1183,7 @@
 ------------
 
 For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
 
 ftrace, trace-cmd, and kernelshark run on the target system, and are
 ready to go out-of-the-box - no additional setup is necessary. For the
@@ -1871,7 +1871,7 @@
 
 So essentially what you need to
 do is build an SDK image or image with 'tools-profile' as detailed in
-the ":ref:`profile-manual/profile-manual-intro:General Setup`" section of this
+the ":ref:`profile-manual/intro:General Setup`" section of this
 manual, and boot the resulting target image.
 
 .. note::
@@ -1954,7 +1954,7 @@
 -------------
 
 For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
 
 Sysprof is a GUI-based application that runs on the target system. For
 the rest of this document we assume you've ssh'ed to the host and will
@@ -2025,7 +2025,7 @@
 -----------
 
 For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
 LTTng is run on the target system by ssh'ing to it.
 
 Collecting and Viewing Traces
@@ -2033,7 +2033,7 @@
 
 Once you've applied the above commits and built and booted your image
 (you need to build the core-image-sato-sdk image or use one of the other
-methods described in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section), you're ready to start
+methods described in the ":ref:`profile-manual/intro:General Setup`" section), you're ready to start
 tracing.
 
 Collecting and viewing a trace on the target (inside a shell)
@@ -2230,14 +2230,14 @@
 --------------
 
 For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`"
+outlined in the ":ref:`profile-manual/intro:General Setup`"
 section.
 
 blktrace is an application that runs on the target system. You can run
 the entire blktrace and blkparse pipeline on the target, or you can run
 blktrace in 'listen' mode on the target and have blktrace and blkparse
 collect and analyze the data on the host (see the
-":ref:`profile-manual/profile-manual-usage:Using blktrace Remotely`" section
+":ref:`profile-manual/usage:Using blktrace Remotely`" section
 below). For the rest of this section we assume you've ssh'ed to the host and
 will be running blkrace on the target.
 
@@ -2512,7 +2512,7 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It's also possible to trace block I/O using only
-:ref:`profile-manual/profile-manual-usage:The 'trace events' Subsystem`, which
+:ref:`profile-manual/usage:The 'trace events' Subsystem`, which
 can be useful for casual tracing if you don't want to bother dealing with the
 userspace tools.
 
diff --git a/poky/documentation/ref-manual/ref-classes.rst b/poky/documentation/ref-manual/classes.rst
similarity index 97%
rename from poky/documentation/ref-manual/ref-classes.rst
rename to poky/documentation/ref-manual/classes.rst
index 249b58e..5a30ce3 100644
--- a/poky/documentation/ref-manual/ref-classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -68,7 +68,7 @@
 materials with the binaries.
 
 For more details on the source archiver, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual. You can also see
 the :term:`ARCHIVER_MODE` variable for information
 about the variable flags (varflags) that help control archive creation.
@@ -86,7 +86,7 @@
 should usually be enough to define a few standard variables and then
 simply ``inherit autotools``. These classes can also work with software
 that emulates Autotools. For more information, see the
-":ref:`new-recipe-autotooled-package`" section
+":ref:`dev-manual/common-tasks:autotooled package`" section
 in the Yocto Project Development Tasks Manual.
 
 By default, the ``autotools*`` classes use out-of-tree builds (i.e.
@@ -236,7 +236,7 @@
 which can be used to detect possible regressions as well as used for
 analysis of the build output. For more information on using Build
 History, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-buildstats:
@@ -406,7 +406,7 @@
 
 The ``cross-canadian`` class provides support for the recipes that build
 the Canadian Cross-compilation tools for SDKs. See the
-":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+":ref:`overview-manual/concepts:cross-development toolchain generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 discussion on these cross-compilation tools.
 
@@ -417,7 +417,7 @@
 
 The ``crosssdk`` class provides support for the recipes that build the
 cross-compilation tools used for building SDKs. See the
-":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+":ref:`overview-manual/concepts:cross-development toolchain generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 discussion on these cross-compilation tools.
 
@@ -458,7 +458,7 @@
 ====================
 
 The ``devshell`` class adds the ``do_devshell`` task. Distribution
-policy dictates whether to include this class. See the ":ref:`platdev-appdev-devshell`"
+policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`"
 section in the Yocto Project Development Tasks Manual for more
 information about using ``devshell``.
 
@@ -586,7 +586,7 @@
 ``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
 For information on how to use the
 ``externalsrc`` class, see the
-":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+":ref:`dev-manual/common-tasks:building software from an external source`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-extrausers:
@@ -927,10 +927,10 @@
    install into the image.
 
 For information on customizing images, see the
-":ref:`usingpoky-extend-customimage`" section
+":ref:`dev-manual/common-tasks:customizing images`" section
 in the Yocto Project Development Tasks Manual. For information on how
 images are created, see the
-":ref:`images-dev-environment`" section in the
+":ref:`overview-manual/concepts:images`" section in the
 Yocto Project Overview and Concpets Manual.
 
 .. _ref-classes-image-buildinfo:
@@ -1033,7 +1033,7 @@
 either raise a warning or an error message. Typically, failures for new
 tests generate a warning. Subsequent failures for the same test would
 then generate an error message once the metadata is in a known and good
-condition. See the ":doc:`ref-qa-checks`" Chapter for a list of all the warning
+condition. See the ":doc:`/ref-manual/qa-checks`" Chapter for a list of all the warning
 and error messages you might encounter using a default configuration.
 
 Use the :term:`WARN_QA` and
@@ -1276,7 +1276,7 @@
 -  ``textrel:`` Checks for ELF binaries that contain relocations in
    their ``.text`` sections, which can result in a performance impact at
    runtime. See the explanation for the ``ELF binary`` message in
-   ":doc:`ref-qa-checks`" for more information regarding runtime performance
+   ":doc:`/ref-manual/qa-checks`" for more information regarding runtime performance
    issues.
 
 -  ``unlisted-pkg-lics:`` Checks that all declared licenses applying
@@ -1344,7 +1344,7 @@
 The ``kernel`` class contains logic that allows you to embed an initial
 RAM filesystem (initramfs) image when you build the kernel image. For
 information on how to build an initramfs, see the
-":ref:`building-an-initramfs-image`" section in
+":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section in
 the Yocto Project Development Tasks Manual.
 
 Various other classes are used by the ``kernel`` and ``module`` classes
@@ -1596,7 +1596,7 @@
 everything needed to build and package a kernel module.
 
 For general information on out-of-tree Linux kernel modules, see the
-":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+":ref:`kernel-dev/common:incorporating out-of-tree modules`"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-classes-module-base:
@@ -1620,7 +1620,7 @@
 them side-by-side in the same image.
 
 For more information on using the Multilib feature, see the
-":ref:`combining-multiple-versions-library-files-into-one-image`"
+":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-native:
@@ -1732,7 +1732,7 @@
    fetcher to have dependencies fetched and packaged automatically.
 
 For information on how to create NPM packages, see the
-":ref:`dev-manual/dev-manual-common-tasks:creating node package manager (npm) packages`"
+":ref:`dev-manual/common-tasks:creating node package manager (npm) packages`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-oelint:
@@ -1802,7 +1802,7 @@
 the development host that can be used by DNF, you can install packages
 from the feed while you are running the image on the target (i.e.
 runtime installation of packages). For more information, see the
-":ref:`dev-manual/dev-manual-common-tasks:using runtime package management`"
+":ref:`dev-manual/common-tasks:using runtime package management`"
 section in the Yocto Project Development Tasks Manual.
 
 The package-specific class you choose can affect build-time performance
@@ -1921,7 +1921,7 @@
 inherit this class.
 
 For information on how to use this class, see the
-":ref:`usingpoky-extend-customimage-customtasks`"
+":ref:`dev-manual/common-tasks:customizing images using custom package groups`"
 section in the Yocto Project Development Tasks Manual.
 
 Previously, this class was called the ``task`` class.
@@ -1986,7 +1986,7 @@
 The ``populate_sdk`` class provides support for SDK-only recipes. For
 information on advantages gained when building a cross-development
 toolchain using the :ref:`ref-tasks-populate_sdk`
-task, see the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+task, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual.
 
@@ -2039,12 +2039,12 @@
 class.
 
 For more information on the cross-development toolchain generation, see
-the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
 section in the Yocto Project Overview and Concepts Manual. For
 information on advantages gained when building a cross-development
 toolchain using the :ref:`ref-tasks-populate_sdk`
 task, see the
-":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual.
 
@@ -2080,7 +2080,7 @@
 ==================
 
 The ``prserv`` class provides functionality for using a :ref:`PR
-service <dev-manual/dev-manual-common-tasks:working with a pr service>` in order to
+service <dev-manual/common-tasks:working with a pr service>` in order to
 automatically manage the incrementing of the :term:`PR`
 variable for each recipe.
 
@@ -2100,7 +2100,7 @@
 This class is intended to be inherited by individual recipes. However,
 the class' functionality is largely disabled unless "ptest" appears in
 :term:`DISTRO_FEATURES`. See the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
 section in the Yocto Project Development Tasks Manual for more information
 on ptest.
 
@@ -2113,7 +2113,7 @@
 have tests intended to be executed with ``gnome-desktop-testing``.
 
 For information on setting up and running ptests, see the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-python-dir:
@@ -2199,7 +2199,7 @@
 ========================
 
 The ``report-error`` class supports enabling the :ref:`error reporting
-tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`",
+tool <dev-manual/common-tasks:using the error reporting tool>`",
 which allows you to submit build error information to a central database.
 
 The class collects debug information for recipe, recipe version, task,
@@ -2268,7 +2268,7 @@
 :term:`PACKAGE_CLASSES` variable.
 
 For information on how root filesystem images are created, see the
-":ref:`image-generation-dev-environment`"
+":ref:`overview-manual/concepts:image generation`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-classes-sanity:
@@ -2375,7 +2375,7 @@
 :term:`INHERIT_DISTRO` variable's default value.
 
 For more information on sstate, see the
-":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+":ref:`overview-manual/concepts:shared state cache`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-classes-staging:
@@ -2554,7 +2554,7 @@
 :term:`SYSTEMD_AUTO_ENABLE` to "disable".
 
 For more information on ``systemd``, see the
-":ref:`dev-manual/dev-manual-common-tasks:selecting an initialization manager`"
+":ref:`dev-manual/common-tasks:selecting an initialization manager`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-systemd-boot:
@@ -2631,7 +2631,7 @@
 :term:`TESTIMAGE_AUTO` must be set to "1").
 
 For information on how to enable, run, and create new tests, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-classes-testsdk:
@@ -2774,7 +2774,7 @@
 These variables list alternative commands needed by a package, provide
 pathnames for links, default links for targets, and so forth. For
 details on how to use this class, see the comments in the
-:yocto_git:`update-alternatives.bbclass </cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass>`
+:yocto_git:`update-alternatives.bbclass </poky/tree/meta/classes/update-alternatives.bbclass>`
 file.
 
 .. note::
diff --git a/poky/documentation/ref-manual/ref-devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-devtool-reference.rst
rename to poky/documentation/ref-manual/devtool-reference.rst
index ad8889e..cc5848f 100644
--- a/poky/documentation/ref-manual/ref-devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -11,7 +11,7 @@
 
 This chapter provides a Quick Reference for the ``devtool`` command. For
 more information on how to apply the command when using the extensible
-SDK, see the ":doc:`../sdk-manual/sdk-extensible`" chapter in the Yocto
+SDK, see the ":doc:`/sdk-manual/extensible`" chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual.
 
@@ -193,7 +193,7 @@
    run your application. If dependent packages (e.g. libraries) do not
    exist on the target, your application, when run, will fail to find
    those functions. For more information, see the
-   ":ref:`ref-manual/ref-devtool-reference:deploying your software on the target machine`"
+   ":ref:`ref-manual/devtool-reference:deploying your software on the target machine`"
    section.
 
 By default, ``devtool add`` uses the latest revision (i.e. master) when
@@ -349,10 +349,10 @@
 .. note::
 
    -  For the ``oe-core`` layer, recipe maintainers come from the
-      `maintainers.inc <http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc>`_
+      :yocto_git:`maintainers.inc </poky/tree/meta/conf/distro/include/maintainers.inc>`
       file.
 
-   -  If the recipe is using the :ref:`bitbake:git-fetcher`
+   -  If the recipe is using the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:git fetcher (\`\`git://\`\`)`
       rather than a
       tarball, the commit hash points to the commit that matches the
       recipe's latest version tag.
@@ -388,7 +388,7 @@
    When a reason for not upgrading displays, the reason is usually
    written into the recipe using the ``RECIPE_NO_UPDATE_REASON``
    variable. See the
-   :yocto_git:`base-passwd.bb </cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>`
+   :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>`
    recipe for an example.
 
 ::
@@ -413,7 +413,7 @@
 As software matures, upstream recipes are upgraded to newer versions. As
 a developer, you need to keep your local recipes up-to-date with the
 upstream version releases. Several methods exist by which you can
-upgrade recipes. You can read about them in the ":ref:`gs-upgrading-recipes`"
+upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
 section of the Yocto Project Development Tasks Manual. This section
 overviews the ``devtool upgrade`` command.
 
@@ -438,10 +438,10 @@
 forth.
 
 You can read more on the ``devtool upgrade`` workflow in the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
+":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual. You can also see an example of
-how to use ``devtool upgrade`` in the ":ref:`gs-using-devtool-upgrade`"
+how to use ``devtool upgrade`` in the ":ref:`dev-manual/common-tasks:using \`\`devtool upgrade\`\``"
 section in the Yocto Project Development Tasks Manual.
 
 .. _devtool-resetting-a-recipe:
@@ -561,7 +561,7 @@
 Use the ``devtool undeploy-target`` command to remove deployed build
 output from the target machine. For the ``devtool undeploy-target``
 command to work, you must have previously used the
-":ref:`devtool deploy-target <ref-manual/ref-devtool-reference:deploying your software on the target machine>`"
+":ref:`devtool deploy-target <ref-manual/devtool-reference:deploying your software on the target machine>`"
 command.
 ::
 
@@ -609,7 +609,7 @@
    $ devtool status
 
 Following is sample output after using
-:ref:`devtool add <ref-manual/ref-devtool-reference:adding a new recipe to the workspace layer>`
+:ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>`
 to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:
 ::
 
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 576863e..f67c538 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -22,7 +22,7 @@
 **A:** You can get the required tools on your host development system a
 couple different ways (i.e. building a tarball or downloading a
 tarball). See the
-":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
 section for steps on how to update your build tools.
 
 **Q:** How can you claim Poky / OpenEmbedded-Core is stable?
@@ -45,9 +45,9 @@
 **A:** Support for an additional board is added by creating a Board
 Support Package (BSP) layer for it. For more information on how to
 create a BSP layer, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section in the Yocto Project Development Tasks Manual and the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
 
 Usually, if the board is not completely exotic, adding support in the
 Yocto Project is fairly straightforward.
@@ -73,7 +73,7 @@
 
 **A:** To add a package, you need to create a BitBake recipe. For
 information on how to create a BitBake recipe, see the
-":ref:`dev-manual/dev-manual-common-tasks:writing a new recipe`"
+":ref:`dev-manual/common-tasks:writing a new recipe`"
 section in the Yocto Project Development Tasks Manual.
 
 **Q:** Do I have to reflash my entire board with a new Yocto Project
@@ -140,7 +140,7 @@
 ``meta-poky/conf/site.conf.sample`` file that shows how to configure CVS
 and Git proxy servers if needed. For more information on setting up
 various proxy types and configuring proxy servers, see the
-":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
 Wiki page.
 
 **Q:** What's the difference between target and target\ ``-native``?
@@ -198,10 +198,10 @@
 configured and built.
 
 You can find more information on licensing in the
-":ref:`overview-manual/overview-manual-development-environment:licensing`"
+":ref:`overview-manual/development-environment:licensing`"
 section in the Yocto
 Project Overview and Concepts Manual and also in the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 **Q:** How do I disable the cursor on my touchscreen device?
@@ -362,7 +362,7 @@
 .. note::
 
    You can find more information on the
-   ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+   ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
    Wiki page.
 
 **Q:** Can I get rid of build output so I can start over?
diff --git a/poky/documentation/ref-manual/ref-features.rst b/poky/documentation/ref-manual/features.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-features.rst
rename to poky/documentation/ref-manual/features.rst
index f28ad2b..89c06eb 100644
--- a/poky/documentation/ref-manual/ref-features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -118,7 +118,7 @@
 -  *api-documentation:* Enables generation of API documentation during
    recipe builds. The resulting documentation is added to SDK tarballs
    when the ``bitbake -c populate_sdk`` command is used. See the
-   ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding api documentation to the standard sdk`"
+   ":ref:`sdk-manual/appendix-customizing-standard:adding api documentation to the standard sdk`"
    section in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual.
 
@@ -156,7 +156,7 @@
 
 -  *ptest:* Enables building the package tests where supported by
    individual recipes. For more information on package tests, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" section
+   ":ref:`dev-manual/common-tasks:testing packages with ptest`" section
    in the Yocto Project Development Tasks Manual.
 
 -  *smbfs:* Include SMB networks client support (for mounting
@@ -236,7 +236,7 @@
 
 -  *read-only-rootfs:* Creates an image whose root filesystem is
    read-only. See the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+   ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
    section in the Yocto Project Development Tasks Manual for more
    information.
 
@@ -261,7 +261,7 @@
 
 -  *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and
    ``LTTng``. For general information on user-space tools, see the
-   :doc:`../sdk-manual/sdk-manual` manual.
+   :doc:`/sdk-manual/index` manual.
 
 -  *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
 
@@ -273,9 +273,9 @@
 
 -  *tools-debug:* Installs debugging tools such as ``strace`` and
    ``gdb``. For information on GDB, see the
-   ":ref:`platdev-gdb-remotedebug`" section
+   ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
    in the Yocto Project Development Tasks Manual. For information on
-   tracing and profiling, see the :doc:`../profile-manual/profile-manual`.
+   tracing and profiling, see the :doc:`/profile-manual/index`.
 
 -  *tools-sdk:* Installs a full SDK that runs on the device.
 
diff --git a/poky/documentation/ref-manual/ref-images.rst b/poky/documentation/ref-manual/images.rst
similarity index 97%
rename from poky/documentation/ref-manual/ref-images.rst
rename to poky/documentation/ref-manual/images.rst
index 56ec856..5e9374e 100644
--- a/poky/documentation/ref-manual/ref-images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -122,7 +122,7 @@
    deployed to a separate partition so that you can boot into it and use
    it to deploy a second image to be tested. You can find more
    information about runtime testing in the
-   ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+   ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
    section in the Yocto Project Development Tasks Manual.
 
 -  ``core-image-testmaster-initramfs``: A RAM-based Initial Root
@@ -132,7 +132,7 @@
 -  ``core-image-weston``: A very basic Wayland image with a terminal.
    This image provides the Wayland protocol libraries and the reference
    Weston compositor. For more information, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using wayland and weston`"
+   ":ref:`dev-manual/common-tasks:using wayland and weston`"
    section in the Yocto Project Development Tasks Manual.
 
 -  ``core-image-x11``: A very basic X11 image with a terminal.
diff --git a/poky/documentation/ref-manual/index.rst b/poky/documentation/ref-manual/index.rst
new file mode 100644
index 0000000..deb0383
--- /dev/null
+++ b/poky/documentation/ref-manual/index.rst
@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+==============================
+Yocto Project Reference Manual
+==============================
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   system-requirements
+   terms
+   release-process
+   migration
+   structure
+   classes
+   tasks
+   devtool-reference
+   kickstart
+   qa-checks
+   images
+   features
+   variables
+   varlocality
+   faq
+   resources
+   history
+
+.. include:: /boilerplate.rst
diff --git a/poky/documentation/ref-manual/ref-kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
similarity index 98%
rename from poky/documentation/ref-manual/ref-kickstart.rst
rename to poky/documentation/ref-manual/kickstart.rst
index 7f6d4eb..bb9c046 100644
--- a/poky/documentation/ref-manual/ref-kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -79,7 +79,7 @@
    source of the data that populates the partition. The most common
    value for this option is "rootfs", but you can use any value that
    maps to a valid source plugin. For information on the source plugins,
-   see the ":ref:`dev-manual/dev-manual-common-tasks:using the wic plugin interface`"
+   see the ":ref:`dev-manual/common-tasks:using the wic plugin interface`"
    section in the Yocto Project Development Tasks Manual.
 
    If you use ``--source rootfs``, Wic creates a partition as large as
diff --git a/poky/documentation/ref-manual/migration-1.3.rst b/poky/documentation/ref-manual/migration-1.3.rst
index 5f97585..12e225b 100644
--- a/poky/documentation/ref-manual/migration-1.3.rst
+++ b/poky/documentation/ref-manual/migration-1.3.rst
@@ -173,7 +173,7 @@
 ``meta-gnome``. For the remainder, you can now find them in the
 ``meta-extras`` repository, which is in the
 :yocto_git:`Source Repositories <>` at
-:yocto_git:`/cgit/cgit.cgi/meta-extras/`.
+:yocto_git:`/meta-extras/`.
 
 .. _1.3-linux-kernel-naming:
 
diff --git a/poky/documentation/ref-manual/migration-1.4.rst b/poky/documentation/ref-manual/migration-1.4.rst
index daaea0f..0b7e861 100644
--- a/poky/documentation/ref-manual/migration-1.4.rst
+++ b/poky/documentation/ref-manual/migration-1.4.rst
@@ -84,7 +84,7 @@
 you can find in the :term:`Source Directory` at
 ``meta/recipes-core/init-ifupdown``. For information on how to use
 append files, see the
-":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.4-remote-debugging:
diff --git a/poky/documentation/ref-manual/migration-1.5.rst b/poky/documentation/ref-manual/migration-1.5.rst
index fc7afac..2716bc9 100644
--- a/poky/documentation/ref-manual/migration-1.5.rst
+++ b/poky/documentation/ref-manual/migration-1.5.rst
@@ -26,7 +26,7 @@
 tarball, which provides an SDK-like environment containing them.
 
 For more information on this requirement, see the
-":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
 section.
 
 .. _migration-1.5-atom-pc-bsp:
@@ -181,7 +181,7 @@
 
 The ``/run`` directory from the Filesystem Hierarchy Standard 3.0 has
 been introduced. You can find some of the implications for this change
-`here <http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873>`__.
+:oe_git:`here </openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873>`.
 The change also means that recipes that install files to ``/var/run``
 must be changed. You can find a guide on how to make these changes
 `here <https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg31649.html>`__.
@@ -246,7 +246,7 @@
 framework replaces the older ``imagetest-qemu`` framework.
 
 You can learn more about performing automated image tests in the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.5-build-history:
@@ -269,7 +269,7 @@
    option for each utility for more information on the new syntax.
 
 For more information on Build History, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.5-udev:
diff --git a/poky/documentation/ref-manual/migration-1.6.rst b/poky/documentation/ref-manual/migration-1.6.rst
index a6c4c8a..ed155d0 100644
--- a/poky/documentation/ref-manual/migration-1.6.rst
+++ b/poky/documentation/ref-manual/migration-1.6.rst
@@ -12,7 +12,7 @@
 The :ref:`archiver <ref-classes-archiver>` class has been rewritten
 and its configuration has been simplified. For more details on the
 source archiver, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.6-packaging-changes:
@@ -126,7 +126,7 @@
 --------------------
 
 The following variables have changed. For information on the
-OpenEmbedded build system variables, see the ":doc:`ref-variables`" Chapter.
+OpenEmbedded build system variables, see the ":doc:`/ref-manual/variables`" Chapter.
 
 .. _migration-1.6-variable-changes-TMPDIR:
 
@@ -148,7 +148,7 @@
 The ``PRINC`` variable has been deprecated and triggers a warning if
 detected during a build. For :term:`PR` increments on changes,
 use the PR service instead. You can find out more about this service in
-the ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`"
+the ":ref:`dev-manual/common-tasks:working with a pr service`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-1.6-variable-changes-IMAGE_TYPES:
@@ -221,7 +221,7 @@
 
 Package Tests (ptest) are built but not installed by default. For
 information on using Package Tests, see the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
 section in the Yocto Project Development Tasks Manual. For information on the
 ``ptest`` class, see the ":ref:`ptest.bbclass <ref-classes-ptest>`"
 section.
@@ -411,6 +411,6 @@
 ``routerstationpro`` machines are still available in a new
 ``meta-yocto-bsp-old`` layer in the
 :yocto_git:`Source Repositories <>` at
-:yocto_git:`/cgit/cgit.cgi/meta-yocto-bsp-old/`.
+:yocto_git:`/meta-yocto-bsp-old/`.
 
 
diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst
index 5a5151e..19275b3 100644
--- a/poky/documentation/ref-manual/migration-1.7.rst
+++ b/poky/documentation/ref-manual/migration-1.7.rst
@@ -26,13 +26,13 @@
 Minimum Git version
 -------------------
 
-The minimum :ref:`overview-manual/overview-manual-development-environment:git`
+The minimum :ref:`overview-manual/development-environment:git`
 version required on the
 build host is now 1.7.8 because the ``--list`` option is now required by
 BitBake's Git fetcher. As always, if your host distribution does not
 provide a version of Git that meets this requirement, you can use the
 ``buildtools-tarball`` that does. See the
-":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
 section for more information.
 
 .. _migration-1.7-autotools-class-changes:
@@ -66,8 +66,8 @@
    foreign mode themselves, the option is mostly superfluous. However,
    some recipes will need patches for this change. You can easily make
    the change by patching ``configure.ac`` so that it passes "foreign"
-   to ``AM_INIT_AUTOMAKE()``. See `this
-   commit <http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2>`__
+   to ``AM_INIT_AUTOMAKE()``. See :oe_git:`this
+   commit </openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2>`
    for an example showing how to make the patch.
 
 .. _migration-1.7-binary-configuration-scripts-disabled:
@@ -157,7 +157,7 @@
    added in order to verify that file dependencies are satisfied (e.g.
    package contains a script requiring ``/bin/bash``) and build-time
    dependencies are declared, respectively. For more information, please
-   see the ":doc:`ref-qa-checks`" chapter.
+   see the ":doc:`/ref-manual/qa-checks`" chapter.
 
 -  Package QA checks are now performed during a new
    :ref:`ref-tasks-package_qa` task rather than being
@@ -217,7 +217,7 @@
    should manually remove old "build-id" files from your existing build
    history repositories to avoid confusion. For information on the build
    history feature, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+   ":ref:`dev-manual/common-tasks:maintaining build output quality`"
    section in the Yocto Project Development Tasks Manual.
 
 
diff --git a/poky/documentation/ref-manual/migration-1.8.rst b/poky/documentation/ref-manual/migration-1.8.rst
index d601e6b..73789bd 100644
--- a/poky/documentation/ref-manual/migration-1.8.rst
+++ b/poky/documentation/ref-manual/migration-1.8.rst
@@ -79,7 +79,7 @@
 inherit from ``kernel-yocto`` or include ``linux-yocto.inc``, you might
 wish to refer to the ``linux.inc`` file in the ``meta-oe`` layer for the
 kinds of changes you need to make. For reference, here is the
-`commit <http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-kernel/linux/linux.inc?id=fc7132ede27ac67669448d3d2845ce7d46c6a1ee>`__
+:oe_git:`commit </meta-openembedded/commit/meta-oe/recipes-kernel/linux/linux.inc?id=fc7132ede27ac67669448d3d2845ce7d46c6a1ee>`
 where the ``linux.inc`` file in ``meta-oe`` was updated.
 
 Recipes that rely on the kernel source code and do not inherit the
diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst
index 0220221..e8b3ada 100644
--- a/poky/documentation/ref-manual/migration-2.1.rst
+++ b/poky/documentation/ref-manual/migration-2.1.rst
@@ -217,7 +217,7 @@
 -  *Hob GTK+-based UI*: Removed because it is unmaintained and based on
    the outdated GTK+ 2 library. The Toaster web-based UI is much more
    capable and is actively maintained. See the
-   ":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`"
+   ":ref:`toaster-manual/setup-and-use:using the toaster web interface`"
    section in the Toaster User Manual for more information on this
    interface.
 
@@ -231,10 +231,10 @@
 
 The Application Development Toolkit (ADT) has been removed because its
 functionality almost completely overlapped with the :ref:`standard
-SDK <sdk-manual/sdk-using:using the standard sdk>` and the
-:ref:`extensible SDK <sdk-manual/sdk-extensible:using the extensible sdk>`. For
+SDK <sdk-manual/using:using the standard sdk>` and the
+:ref:`extensible SDK <sdk-manual/extensible:using the extensible sdk>`. For
 information on these SDKs and how to build and use them, see the
-:doc:`../sdk-manual/sdk-manual` manual.
+:doc:`/sdk-manual/index` manual.
 
 .. note::
 
@@ -346,7 +346,7 @@
 files through GObject introspection, which is the standard mechanism for
 accessing GObject-based software from runtime environments. You can
 enable, disable, and test the generation of this data. See the
-":ref:`dev-manual/dev-manual-common-tasks:enabling gobject introspection support`"
+":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
 section in the Yocto Project Development Tasks Manual for more
 information.
 
@@ -360,7 +360,7 @@
 -  The minimum Git version has been increased to 1.8.3.1. If your host
    distribution does not provide a sufficiently recent version, you can
    install the buildtools, which will provide it. See the
-   :ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`
+   :ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
    section for more information on the buildtools tarball.
 
 -  The buggy and incomplete support for the RPM version 4 package
@@ -386,7 +386,7 @@
    removed at runtime).
 
 -  The
-   :ref:`devtool modify <sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
+   :ref:`devtool modify <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
    command now defaults to extracting the source since that is most
    commonly expected. The "-x" or "--extract" options are now no-ops. If
    you wish to provide your own existing source tree, you will now need
diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst
index 8afa8ff..ac247dc 100644
--- a/poky/documentation/ref-manual/migration-2.2.rst
+++ b/poky/documentation/ref-manual/migration-2.2.rst
@@ -292,9 +292,9 @@
    functionality. These changes will affect external tools that use
    BitBake's tinfoil module. For information on these changes, see the
    changes made to the scripts supplied with OpenEmbedded-Core:
-   `1 <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=189371f8393971d00bca0fceffd67cc07784f6ee>`__
+   :yocto_git:`1 </poky/commit/?id=189371f8393971d00bca0fceffd67cc07784f6ee>`
    and
-   `2 <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4a5aa7ea4d07c2c90a1654b174873abb018acc67>`__.
+   :yocto_git:`2 </poky/commit/?id=4a5aa7ea4d07c2c90a1654b174873abb018acc67>`.
 
 -  The task management code has been rewritten to avoid using ID
    indirection in order to improve performance. This change is unlikely
diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst
index 5bf3e70..3e97581 100644
--- a/poky/documentation/ref-manual/migration-2.3.rst
+++ b/poky/documentation/ref-manual/migration-2.3.rst
@@ -51,7 +51,7 @@
    :term:`SYSROOT_PREPROCESS_FUNCS`.
 
    For an example, see the ``pixbufcache`` class in ``meta/classes/`` in
-   the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+   the :ref:`overview-manual/development-environment:yocto project source repositories`.
 
    .. note::
 
@@ -198,7 +198,7 @@
    fetcher passes the new parameter through the ``SVN_SSH`` environment
    variable during the :ref:`ref-tasks-fetch` task.
 
-   See the ":ref:`bitbake:svn-fetcher`"
+   See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:subversion (svn) fetcher (\`\`svn://\`\`)`"
    section in the BitBake
    User Manual for additional information.
 
@@ -323,7 +323,7 @@
    .. note::
 
       For further details on this change, see the
-      :yocto_git:`commit message </cgit/cgit.cgi/poky/commit/?id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81>`.
+      :yocto_git:`commit message </poky/commit/?id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81>`.
 
 .. _migration-2.3-removed-recipes:
 
@@ -366,7 +366,7 @@
 .. note::
 
    For more information on Wic, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+   ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Default Output Directory Changed:* Wic's default output directory is
@@ -404,7 +404,7 @@
 
    For additional information, see the
    :ref:`insane <ref-classes-insane>` class and the
-   ":ref:`ref-manual/ref-qa-checks:errors and warnings`" section.
+   ":ref:`ref-manual/qa-checks:errors and warnings`" section.
 
 .. _migration-2.3-miscellaneous-changes:
 
diff --git a/poky/documentation/ref-manual/migration-2.5.rst b/poky/documentation/ref-manual/migration-2.5.rst
index 1aeddc8..9f45ffc 100644
--- a/poky/documentation/ref-manual/migration-2.5.rst
+++ b/poky/documentation/ref-manual/migration-2.5.rst
@@ -180,7 +180,7 @@
 The earlier build-time provides behavior was a quirk of the
 way the Python manifest file was created. For more information on this
 change please see :yocto_git:`this commit
-</cgit/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`.
+</poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`.
 
 .. _migration-2.5-miscellaneous-changes:
 
@@ -266,7 +266,7 @@
    will trigger a warning during ``do_rootfs``.
 
    For more information, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+   ":ref:`dev-manual/common-tasks:post-installation scripts`"
    section in the Yocto Project Development Tasks Manual.
 
 -  The ``elf`` image type has been removed. This image type was removed
@@ -293,8 +293,8 @@
 
 -  Patches whose context does not match exactly (i.e. where patch
    reports "fuzz" when applying) will generate a warning. For an example
-   of this see `this
-   commit <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=cc97bc08125b63821ce3f616771830f77c456f57>`__.
+   of this see :yocto_git:`this commit
+   </poky/commit/?id=cc97bc08125b63821ce3f616771830f77c456f57>`.
 
 -  Layers are expected to set ``LAYERSERIES_COMPAT_layername`` to match
    the version(s) of OpenEmbedded-Core they are compatible with. This is
diff --git a/poky/documentation/ref-manual/migration-2.6.rst b/poky/documentation/ref-manual/migration-2.6.rst
index 2f0da48..5d524f3 100644
--- a/poky/documentation/ref-manual/migration-2.6.rst
+++ b/poky/documentation/ref-manual/migration-2.6.rst
@@ -278,7 +278,7 @@
    specifying list items to remove, be aware that leading and trailing
    whitespace resulting from the removal is retained.
 
-   See the ":ref:`bitbake:removing-override-style-syntax`"
+   See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`"
    section in the BitBake User Manual for a detailed example.
 
 .. _migration-2.6-systemd-configuration-now-split-out-to-system-conf:
@@ -372,7 +372,7 @@
 an error during the :ref:`ref-tasks-rootfs` task.
 
 For more information on post-installation behavior, see the
-":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+":ref:`dev-manual/common-tasks:post-installation scripts`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _migration-2.6-python-3-profile-guided-optimizations:
diff --git a/poky/documentation/ref-manual/migration-3.0.rst b/poky/documentation/ref-manual/migration-3.0.rst
index 047b755..7ef2742 100644
--- a/poky/documentation/ref-manual/migration-3.0.rst
+++ b/poky/documentation/ref-manual/migration-3.0.rst
@@ -197,7 +197,7 @@
 -  The arguments passed to functions used with
    :term:`bitbake:BB_HASHCHECK_FUNCTION`
    have changed. If you are using your own custom hash check function,
-   see :yocto_git:`/cgit/cgit.cgi/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725`
+   see :yocto_git:`/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725`
    for details.
 
 -  Task specifications in ``BB_TASKDEPDATA`` and class implementations
diff --git a/poky/documentation/ref-manual/migration-3.2.rst b/poky/documentation/ref-manual/migration-3.2.rst
index 9b65e26..65a9ff4 100644
--- a/poky/documentation/ref-manual/migration-3.2.rst
+++ b/poky/documentation/ref-manual/migration-3.2.rst
@@ -71,7 +71,7 @@
 In addition, pseudo's behaviour on mismatches has now been changed - rather
 than doing what turns out to be a rather dangerous "fixup" if it sees a file
 with a different path but the same inode as another file it has previously seen,
-pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </wiki/Pseudo_Abort>`
+pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </Pseudo_Abort>`
 that explains how to deal with this.
 
 
diff --git a/poky/documentation/ref-manual/ref-qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
similarity index 100%
rename from poky/documentation/ref-manual/ref-qa-checks.rst
rename to poky/documentation/ref-manual/qa-checks.rst
diff --git a/poky/documentation/ref-manual/ref-manual.rst b/poky/documentation/ref-manual/ref-manual.rst
deleted file mode 100644
index 033f4ba..0000000
--- a/poky/documentation/ref-manual/ref-manual.rst
+++ /dev/null
@@ -1,31 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-==============================
-Yocto Project Reference Manual
-==============================
-
-|
-
-.. toctree::
-   :caption: Table of Contents
-   :numbered:
-
-   ref-system-requirements
-   ref-terms
-   ref-release-process
-   migration
-   ref-structure
-   ref-classes
-   ref-tasks
-   ref-devtool-reference
-   ref-kickstart
-   ref-qa-checks
-   ref-images
-   ref-features
-   ref-variables
-   ref-varlocality
-   faq
-   resources
-   history
-
-.. include:: /boilerplate.rst
diff --git a/poky/documentation/ref-manual/ref-release-process.rst b/poky/documentation/ref-manual/release-process.rst
similarity index 93%
rename from poky/documentation/ref-manual/ref-release-process.rst
rename to poky/documentation/ref-manual/release-process.rst
index a6d9ff6..d8d3622 100644
--- a/poky/documentation/ref-manual/ref-release-process.rst
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -50,7 +50,7 @@
 =======================
 
 Each major release receives a codename that identifies the release in
-the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+the :ref:`overview-manual/development-environment:yocto project source repositories`.
 The concept is that branches of :term:`Metadata` with the same
 codename are likely to be compatible and thus work together.
 
@@ -64,7 +64,7 @@
 Releases are given a nominal release version as well but the codename is
 used in repositories for this reason. You can find information on Yocto
 Project releases and codenames at
-:yocto_wiki:`/wiki/Releases`.
+:yocto_wiki:`/Releases`.
 
 Stable Release Process
 ======================
@@ -94,7 +94,7 @@
 patches for older releases. However, these types of patches do not go
 through the same release process as do point releases. You can find more
 information about stable branch maintenance at
-:yocto_wiki:`/wiki/Stable_branch_maintenance`.
+:yocto_wiki:`/Stable_branch_maintenance`.
 
 Testing and Quality Assurance
 =============================
@@ -106,7 +106,7 @@
 developer, you can validate your projects. This section overviews the
 available test infrastructure used in the Yocto Project. For information
 on how to run available tests on your projects, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 The QA/testing infrastructure is woven into the project to the point
@@ -128,12 +128,12 @@
 
 -  :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
    performs runtime testing of images after they are built. The tests
-   are usually used with :doc:`QEMU <../dev-manual/dev-manual-qemu>`
+   are usually used with :doc:`QEMU </dev-manual/qemu>`
    to boot the images and check the combined runtime result boot
    operation and functions. However, the test can also use the IP
    address of a machine to test.
 
--  :ref:`ptest <dev-manual/dev-manual-common-tasks:testing packages with ptest>`:
+-  :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`:
    Runs tests against packages produced during the build for a given
    piece of software. The test allows the packages to be be run within a
    target image.
@@ -146,7 +146,7 @@
    .. note::
 
       Running ``oe-selftest`` requires host packages beyond the "Essential"
-      grouping. See the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+      grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host`
       section for more information.
 
 Originally, much of this testing was done manually. However, significant
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index 2ef182f..77c3678 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -23,7 +23,7 @@
 to the project either by creating and sending pull requests, or by
 submitting patches through email. For information on how to do both as
 well as information on how to identify the maintainer for each area of
-code, see the ":ref:`how-to-submit-a-change`" section in the
+code, see the ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" section in the
 Yocto Project Development Tasks Manual.
 
 .. _resources-bugtracker:
@@ -47,10 +47,10 @@
 submit a bug. For information on how to use Bugzilla to submit a bug
 against the Yocto Project, see the following:
 
--  The ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
+-  The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
    section in the Yocto Project Development Tasks Manual.
 
--  The Yocto Project :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
+-  The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
 
 For information on Bugzilla in general, see http://www.bugzilla.org/about/.
 
@@ -108,7 +108,7 @@
 -  :yocto_home:`The Yocto Project Website <>`\ *:* The home site
    for the Yocto Project.
 
--  :yocto_wiki:`The Yocto Project Main Wiki Page </wiki/Main_Page>`\ *:* The main wiki page for
+-  :yocto_wiki:`The Yocto Project Main Wiki Page <>`\ *:* The main wiki page for
    the Yocto Project. This page contains information about project
    planning, release engineering, QA & automation, a reference site map,
    and other resources related to the Yocto Project.
@@ -125,33 +125,33 @@
    guide to the BitBake tool. If you want information on BitBake, see
    this manual.
 
--  :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` *:* This
+-  :doc:`/brief-yoctoprojectqs/index` *:* This
    short document lets you experience building an image using the Yocto
    Project without having to understand any concepts or details.
 
--  :doc:`../overview-manual/overview-manual` *:* This manual provides overview
+-  :doc:`/overview-manual/index` *:* This manual provides overview
    and conceptual information about the Yocto Project.
 
--  :doc:`../dev-manual/dev-manual` *:* This manual is a "how-to" guide
+-  :doc:`/dev-manual/index` *:* This manual is a "how-to" guide
    that presents procedures useful to both application and system
    developers who use the Yocto Project.
 
--  :doc:`../sdk-manual/sdk-manual` *manual :* This
+-  :doc:`/sdk-manual/index` *manual :* This
    guide provides information that lets you get going with the standard
    or extensible SDK. An SDK, with its cross-development toolchains,
    allows you to develop projects inside or outside of the Yocto Project
    environment.
 
--  :doc:`../bsp-guide/bsp` *:* This guide defines the structure
+-  :doc:`/bsp-guide/bsp` *:* This guide defines the structure
    for BSP components. Having a commonly understood structure encourages
    standardization.
 
--  :doc:`../kernel-dev/kernel-dev` *:* This manual describes
+-  :doc:`/kernel-dev/index` *:* This manual describes
    how to work with Linux Yocto kernels as well as provides a bit of
    conceptual information on the construction of the Yocto Linux kernel
    tree.
 
--  :doc:`../ref-manual/ref-manual` *:* This
+-  :doc:`/ref-manual/index` *:* This
    manual provides reference material such as variable, task, and class
    descriptions.
 
@@ -161,17 +161,17 @@
    which you can easily search for phrases and terms used in the Yocto
    Project documentation set.
 
--  :doc:`../profile-manual/profile-manual` *:* This manual presents a set of
+-  :doc:`/profile-manual/index` *:* This manual presents a set of
    common and generally useful tracing and profiling schemes along with
    their applications (as appropriate) to each tool.
 
--  :doc:`../toaster-manual/toaster-manual` *:* This manual
+-  :doc:`/toaster-manual/index` *:* This manual
    introduces and describes how to set up and use Toaster. Toaster is an
    Application Programming Interface (API) and web-based interface to
    the :term:`OpenEmbedded Build System`, which uses
    BitBake, that reports build information.
 
--  :yocto_wiki:`FAQ </wiki/FAQ>`\ *:* A list of commonly asked
+-  :yocto_wiki:`FAQ </FAQ>`\ *:* A list of commonly asked
    questions and their answers.
 
 -  *Release Notes:* Features, updates and known issues for the current
@@ -184,7 +184,8 @@
    the Yocto Project uses. If you find problems with the Yocto Project,
    you should report them using this application.
 
--  :yocto_wiki:`Bugzilla Configuration and Bug Tracking Wiki Page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`\ *:*
+-  :yocto_wiki:`Bugzilla Configuration and Bug Tracking Wiki Page
+   </Bugzilla_Configuration_and_Bug_Tracking>`\ *:*
    Information on how to get set up and use the Yocto Project
    implementation of Bugzilla for logging and tracking Yocto Project
    defects.
diff --git a/poky/documentation/ref-manual/ref-structure.rst b/poky/documentation/ref-manual/structure.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-structure.rst
rename to poky/documentation/ref-manual/structure.rst
index db1ea97..ad3f4ab 100644
--- a/poky/documentation/ref-manual/ref-structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -12,7 +12,7 @@
 
 For information on how to establish a local Source Directory on your
 development system, see the
-":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+":ref:`dev-manual/start:locating yocto project source files`"
 section in the Yocto Project Development Tasks Manual.
 
 .. note::
@@ -104,7 +104,7 @@
 
 This directory contains the Yocto Project reference hardware Board
 Support Packages (BSPs). For more information on BSPs, see the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
 
 .. _structure-meta-selftest:
 
@@ -176,7 +176,7 @@
 custom distribution, you can include your own version of this
 configuration file to mention the targets defined by your distribution.
 See the
-":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
+":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
 section in the Yocto Project Development Tasks Manual for more
 information.
 
@@ -193,7 +193,7 @@
 The OpenEmbedded build system uses the template configuration files, which
 are found by default in the ``meta-poky/conf/`` directory in the Source
 Directory. See the
-":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
+":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
 section in the Yocto Project Development Tasks Manual for more
 information.
 
@@ -236,7 +236,7 @@
 build history via the ``buildhistory`` class file. The directory
 organizes build information into image, packages, and SDK
 subdirectories. For information on the build history feature, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _structure-build-conf-local.conf:
@@ -292,7 +292,7 @@
 ----------------------------
 
 This configuration file defines
-:ref:`layers <dev-manual/dev-manual-common-tasks:understanding and creating layers>`,
+:ref:`layers <dev-manual/common-tasks:understanding and creating layers>`,
 which are directory trees, traversed (or walked) by BitBake. The
 ``bblayers.conf`` file uses the :term:`BBLAYERS`
 variable to list the layers BitBake tries to find.
@@ -399,8 +399,8 @@
 build process. The :term:`DEPLOY_DIR` variable points
 to this directory. For more detail on the contents of the ``deploy``
 directory, see the
-":ref:`images-dev-environment`" and
-":ref:`sdk-dev-environment`" sections in the Yocto
+":ref:`overview-manual/concepts:images`" and
+":ref:`overview-manual/concepts:application development sdk`" sections in the Yocto
 Project Overview and Concepts Manual.
 
 .. _structure-build-tmp-deploy-deb:
@@ -438,7 +438,7 @@
 ``glibc`` (among others) that in turn contain appropriate ``COPYING``
 license files with other licensing information. For information on
 licensing, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _structure-build-tmp-deploy-images:
@@ -477,7 +477,7 @@
 The OpenEmbedded build system creates this directory to hold toolchain
 installer scripts which, when executed, install the sysroot that matches
 your target hardware. You can find out more about these installers in
-the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual.
 
@@ -545,7 +545,7 @@
 
 For information on how BitBake uses stamp files to determine if a task
 should be rerun, see the
-":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _structure-build-tmp-log:
@@ -577,7 +577,7 @@
 ``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
 to as the ``WORKDIR``, is created. Within this directory, the source is
 unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
-(See the ":ref:`using-a-quilt-workflow`" section in
+(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
 the Yocto Project Development Tasks Manual for more information.) Within
 the ``linux-qemux86-standard-build`` directory, standard Quilt
 directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
@@ -682,7 +682,7 @@
 ``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``.
 
 For reference information on classes, see the
-":ref:`ref-manual/ref-classes:Classes`" chapter.
+":ref:`ref-manual/classes:Classes`" chapter.
 
 .. _structure-meta-conf:
 
diff --git a/poky/documentation/ref-manual/ref-system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-system-requirements.rst
rename to poky/documentation/ref-manual/system-requirements.rst
index fe7c925..66afb08 100644
--- a/poky/documentation/ref-manual/ref-system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -15,14 +15,14 @@
 
 For introductory information on the Yocto Project, see the
 :yocto_home:`Yocto Project Website <>` and the
-":ref:`overview-manual/overview-manual-development-environment:the yocto project development environment`"
+":ref:`overview-manual/development-environment:the yocto project development environment`"
 chapter in the Yocto Project Overview and Concepts Manual.
 
 If you want to use the Yocto Project to quickly build an image without
 having to understand concepts, work through the
-:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document. You can find "how-to"
-information in the :doc:`../dev-manual/dev-manual`. You can find Yocto Project overview
-and conceptual information in the :doc:`../overview-manual/overview-manual`.
+:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to"
+information in the :doc:`/dev-manual/index`. You can find Yocto Project overview
+and conceptual information in the :doc:`/overview-manual/index`.
 
 .. note::
 
@@ -93,8 +93,8 @@
       Bugzilla <>` and submit a bug. We are
       interested in hearing about your experience. For information on
       how to submit a bug, see the Yocto Project
-      :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
-      and the ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
+      :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
+      and the ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
       section in the Yocto Project Development Tasks Manual.
 
 
diff --git a/poky/documentation/ref-manual/ref-tasks.rst b/poky/documentation/ref-manual/tasks.rst
similarity index 92%
rename from poky/documentation/ref-manual/ref-tasks.rst
rename to poky/documentation/ref-manual/tasks.rst
index 9ef0141..9fe1c29 100644
--- a/poky/documentation/ref-manual/ref-tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -122,7 +122,7 @@
 
 Fetches the source code. This task uses the
 :term:`SRC_URI` variable and the argument's prefix to
-determine the correct :ref:`fetcher <bitbake:bb-fetchers>`
+determine the correct :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
 module.
 
 .. _ref-tasks-image:
@@ -140,7 +140,7 @@
 :term:`IMAGE_PREPROCESS_COMMAND` and
 dynamically generates supporting ``do_image_*`` tasks as needed.
 
-For more information on image creation, see the ":ref:`image-generation-dev-environment`"
+For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-image-complete:
@@ -159,7 +159,7 @@
 :term:`IMAGE_POSTPROCESS_COMMAND`.
 
 For more information on image creation, see the
-":ref:`image-generation-dev-environment`"
+":ref:`overview-manual/concepts:image generation`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-install:
@@ -174,7 +174,7 @@
 that either directly or indirectly depend on the installed files (e.g.
 :ref:`ref-tasks-package`, ``do_package_write_*``, and
 :ref:`ref-tasks-rootfs`), run under
-:ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
+:ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
 
 .. note::
 
@@ -218,7 +218,7 @@
 :ref:`ref-tasks-packagedata` task, also saves some
 important package metadata. For additional information, see the
 :term:`PKGDESTWORK` variable and the
-":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+":ref:`overview-manual/concepts:automatically added runtime dependencies`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_qa:
@@ -237,7 +237,7 @@
 Creates Debian packages (i.e. ``*.deb`` files) and places them in the
 ``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in
 the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_write_ipk:
@@ -248,7 +248,7 @@
 Creates IPK packages (i.e. ``*.ipk`` files) and places them in the
 ``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in
 the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_write_rpm:
@@ -259,7 +259,7 @@
 Creates RPM packages (i.e. ``*.rpm`` files) and places them in the
 ``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in
 the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-package_write_tar:
@@ -270,7 +270,7 @@
 Creates tarballs and places them in the
 ``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in
 the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
 the Yocto Project Overview and Concepts Manual.
 
 .. _ref-tasks-packagedata:
@@ -301,7 +301,7 @@
 Patch files, by default, are ``*.patch`` and ``*.diff`` files created
 and kept in a subdirectory of the directory holding the recipe file. For
 example, consider the
-:yocto_git:`bluez5 </cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/bluez5>`
+:yocto_git:`bluez5 </poky/tree/meta/recipes-connectivity/bluez5>`
 recipe from the OE-Core layer (i.e. ``poky/meta``):
 ::
 
@@ -349,9 +349,9 @@
 applied as a patch by default except for the ``patch_file5`` patch.
 
 You can find out more about the patching process in the
-":ref:`patching-dev-environment`" section in
+":ref:`overview-manual/concepts:patching`" section in
 the Yocto Project Overview and Concepts Manual and the
-":ref:`new-recipe-patching-code`" section in the
+":ref:`dev-manual/common-tasks:patching code`" section in the
 Yocto Project Development Tasks Manual.
 
 .. _ref-tasks-populate_lic:
@@ -368,7 +368,7 @@
 -------------------
 
 Creates the file and directory structure for an installable SDK. See the
-":ref:`sdk-generation-dev-environment`"
+":ref:`overview-manual/concepts:sdk generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 information.
 
@@ -378,7 +378,7 @@
 -----------------------
 
 Creates the file and directory structure for an installable extensible 
-SDK (eSDK). See the ":ref:`sdk-generation-dev-environment`"
+SDK (eSDK). See the ":ref:`overview-manual/concepts:sdk generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 information.
 
@@ -434,7 +434,7 @@
 ``${``\ :term:`WORKDIR`\ ``}``. The :term:`S`
 variable also plays a role in where unpacked source files ultimately
 reside. For more information on how source files are unpacked, see the
-":ref:`source-fetching-dev-environment`"
+":ref:`overview-manual/concepts:source fetching`"
 section in the Yocto Project Overview and Concepts Manual and also see
 the ``WORKDIR`` and ``S`` variable descriptions.
 
@@ -461,7 +461,7 @@
    $ devtool latest-version
    $ devtool check-upgrade-status
 
-See the ":ref:`ref-manual/ref-devtool-reference:\`\`devtool\`\` quick reference`"
+See the ":ref:`ref-manual/devtool-reference:\`\`devtool\`\` quick reference`"
 chapter for more information on
 ``devtool``. See the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
 section for information on checking the upgrade status of a recipe.
@@ -500,7 +500,7 @@
    $ bitbake -c clean recipe
 
 Running this task does not remove the
-:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>` cache files.
+:ref:`sstate <overview-manual/concepts:shared state cache>` cache files.
 Consequently, if no changes have been made and the recipe is rebuilt
 after cleaning, output files are simply restored from the sstate cache.
 If you want to remove the sstate cache files for the recipe, you need to
@@ -513,7 +513,7 @@
 ---------------
 
 Removes all output files, shared state
-(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, and
+(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and
 downloaded source files for a target (i.e. the contents of
 :term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
 identical to the :ref:`ref-tasks-cleansstate` task
@@ -534,10 +534,10 @@
 ------------------
 
 Removes all output files and shared state
-(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache for a
+(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a
 target. Essentially, the ``do_cleansstate`` task is identical to the
 :ref:`ref-tasks-clean` task with the added removal of
-shared state (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`)
+shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`)
 cache.
 
 You can run this task using BitBake as follows:
@@ -567,7 +567,7 @@
 Starts a shell in which an interactive Python interpreter allows you to
 interact with the BitBake build environment. From within this shell, you
 can directly examine and set bits from the data store and execute
-functions as if within the BitBake environment. See the ":ref:`platdev-appdev-devpyshell`" section in
+functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a development python shell`" section in
 the Yocto Project Development Tasks Manual for more information about
 using ``devpyshell``.
 
@@ -577,7 +577,7 @@
 ---------------
 
 Starts a shell whose environment is set up for development, debugging,
-or both. See the ":ref:`platdev-appdev-devshell`" section in the
+or both. See the ":ref:`dev-manual/common-tasks:using a development shell`" section in the
 Yocto Project Development Tasks Manual for more information about using
 ``devshell``.
 
@@ -593,7 +593,7 @@
 ``do_package_index``
 --------------------
 
-Creates or updates the index in the :ref:`package-feeds-dev-environment` area.
+Creates or updates the index in the :ref:`overview-manual/concepts:package feeds` area.
 
 .. note::
 
@@ -631,7 +631,7 @@
 -------------
 
 Creates the root filesystem (file and directory structure) for an image.
-See the ":ref:`image-generation-dev-environment`"
+See the ":ref:`overview-manual/concepts:image generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 information on how the root filesystem is created.
 
@@ -642,7 +642,7 @@
 
 Boots an image and performs runtime tests within the image. For
 information on automatically testing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 .. _ref-tasks-testimage_auto:
@@ -655,7 +655,7 @@
 :term:`TESTIMAGE_AUTO` equal to "1".
 
 For information on automatically testing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
 section in the Yocto Project Development Tasks Manual.
 
 Kernel-Related Tasks
@@ -693,7 +693,7 @@
    $ bitbake linux-yocto -c diffconfig
 
 For more information, see the
-":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+":ref:`kernel-dev/common:creating configuration fragments`"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-tasks-kernel_checkout:
@@ -724,7 +724,7 @@
    $ bitbake linux-yocto -c kernel_configcheck -f
 
 For more information, see the
-":ref:`kernel-dev/kernel-dev-common:validating configuration`"
+":ref:`kernel-dev/common:validating configuration`"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-tasks-kernel_configme:
@@ -756,7 +756,7 @@
            $ bitbake linux-yocto -c menuconfig
 
 
-See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
 section in the Yocto Project Linux Kernel Development Manual for more
 information on this configuration tool.
 
@@ -780,7 +780,7 @@
 
 Runs ``make menuconfig`` for the kernel. For information on
 ``menuconfig``, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
 section in the Yocto Project Linux Kernel Development Manual.
 
 .. _ref-tasks-savedefconfig:
diff --git a/poky/documentation/ref-manual/ref-terms.rst b/poky/documentation/ref-manual/terms.rst
similarity index 92%
rename from poky/documentation/ref-manual/ref-terms.rst
rename to poky/documentation/ref-manual/terms.rst
index b4ceebc..c07dd4b 100644
--- a/poky/documentation/ref-manual/ref-terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -21,7 +21,7 @@
 
       Information in append files extends or overrides the information in the
       similarly-named recipe file. For an example of an append file in use, see
-      the ":ref:`dev-manual/dev-manual-common-tasks:Using .bbappend Files in
+      the ":ref:`dev-manual/common-tasks:Using .bbappend Files in
       Your Layer`" section in the Yocto Project Development Tasks Manual.
 
       When you name an append file, you can use the "``%``" wildcard character
@@ -58,14 +58,13 @@
    :term:`Board Support Package (BSP)`
       A group of drivers, definitions, and other components that provide support
       for a specific hardware configuration. For more information on BSPs, see
-      the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package
-      Developer's Guide`.
+      the :doc:`/bsp-guide/index`.
 
    :term:`Build Directory`
       This term refers to the area used by the OpenEmbedded build system for
       builds. The area is created when you ``source`` the setup environment
       script that is found in the Source Directory
-      (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``). The
+      (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The
       :term:`TOPDIR` variable points to the Build Directory.
 
       You have a lot of flexibility when creating the Build Directory.
@@ -118,7 +117,7 @@
       Files that provide for logic encapsulation and inheritance so that
       commonly used patterns can be defined once and then easily used in
       multiple recipes. For reference information on the Yocto Project classes,
-      see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the
+      see the ":ref:`ref-manual/classes:Classes`" chapter. Class files end with the
       ``.bbclass`` filename extension.
 
    :term:`Configuration File`
@@ -161,27 +160,24 @@
 
       Creation of these toolchains is simple and automated. For information on
       toolchain concepts as they apply to the Yocto Project, see the
-      ":ref:`overview-manual/overview-manual-concepts:Cross-Development
+      ":ref:`overview-manual/concepts:Cross-Development
       Toolchain Generation`" section in the Yocto Project Overview and Concepts
       Manual. You can also find more information on using the relocatable
-      toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application
-      Development and the Extensible Software Development Kit (eSDK)` manual.
+      toolchain in the :doc:`/sdk-manual/index` manual.
 
    :term:`Extensible Software Development Kit (eSDK)`
       A custom SDK for application developers. This eSDK allows developers to
       incorporate their library and programming changes back into the image to
       make their code available to other application developers.
 
-      For information on the eSDK, see the :ref:`sdk-manual/sdk-manual:Yocto
-      Project Application Development and the Extensible Software Development
-      Kit (eSDK)` manual.
+      For information on the eSDK, see the :doc:`/sdk-manual/index` manual.
 
    :term:`Image`
       An image is an artifact of the BitBake build process given a collection of
       recipes and related Metadata. Images are the binary output that run on
       specific hardware or QEMU and are used for specific use-cases. For a list
       of the supported image types that the Yocto Project provides, see the
-      ":ref:`ref-manual/ref-images:Images`" chapter.
+      ":ref:`ref-manual/images:Images`" chapter.
 
    :term:`Layer`
       A collection of related recipes. Layers allow you to consolidate related
@@ -193,10 +189,10 @@
       layers used within Yocto Project.
 
       For introductory information on layers, see the
-      ":ref:`overview-manual/overview-manual-yp-intro:The Yocto Project Layer
+      ":ref:`overview-manual/yp-intro:The Yocto Project Layer
       Model`" section in the Yocto Project Overview and Concepts Manual. For
       more detailed information on layers, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:Understanding and Creating
+      ":ref:`dev-manual/common-tasks:Understanding and Creating
       Layers`" section in the Yocto Project Development Tasks Manual. For a
       discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP
       Layers`" section in the Yocto Project Board Support Packages (BSP)
@@ -218,7 +214,7 @@
 
       In the context of the kernel ("kernel Metadata"), the term refers to
       the kernel config fragments and features contained in the
-      :yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache>`
+      :yocto_git:`yocto-kernel-cache </yocto-kernel-cache>`
       Git repository.
 
    :term:`OpenEmbedded-Core (OE-Core)`
@@ -232,7 +228,7 @@
       core set of recipes.
 
       You can see the Metadata in the ``meta`` directory of the Yocto
-      Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky>`.
+      Project :yocto_git:`Source Repositories </poky>`.
 
    :term:`OpenEmbedded Build System`
       The build system specific to the Yocto
@@ -256,7 +252,7 @@
 
       It is worth noting that the term "package" can, in general, have
       subtle meanings. For example, the packages referred to in the
-      ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+      ":ref:`ref-manual/system-requirements:required packages for the build host`"
       section are compiled binaries that, when installed, add functionality to
       your Linux distribution.
 
@@ -370,7 +366,7 @@
 
      For more information on concepts related to Git repositories,
      branches, and tags, see the
-     ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`"
+     ":ref:`overview-manual/development-environment:repositories, tags, and branches`"
      section in the Yocto Project Overview and Concepts Manual.
 
    :term:`Task`
@@ -384,7 +380,7 @@
       The interface enables you to
       configure and run your builds. Information about builds is collected
       and stored in a database. For information on Toaster, see the
-      :doc:`../toaster-manual/toaster-manual`.
+      :doc:`/toaster-manual/index`.
 
    :term:`Upstream`
       A reference to source code or repositories that are not
diff --git a/poky/documentation/ref-manual/ref-variables.rst b/poky/documentation/ref-manual/variables.rst
similarity index 97%
rename from poky/documentation/ref-manual/ref-variables.rst
rename to poky/documentation/ref-manual/variables.rst
index e552351..8c6cc46 100644
--- a/poky/documentation/ref-manual/ref-variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -239,7 +239,7 @@
       so that it does contain ``${SRCPV}``.
 
       For more information see the
-      ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+      ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`AVAILABLE_LICENSES`
@@ -261,7 +261,7 @@
       The list simply presents the tunes that are available. Not all tunes
       may be compatible with a particular machine configuration, or with
       each other in a
-      :ref:`Multilib <dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image>`
+      :ref:`Multilib <dev-manual/common-tasks:combining multiple versions of library files into one image>`
       configuration.
 
       To add a tune to the list, be sure to append it with spaces using the
@@ -317,7 +317,7 @@
    :term:`BASE_LIB`
       The library directory name for the CPU or Application Binary
       Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib
-      context. See the ":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`"
+      context. See the ":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
       section in the Yocto Project Development Tasks Manual for information
       on Multilib.
 
@@ -545,7 +545,7 @@
       is not set higher than "20".
 
       For more information on speeding up builds, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+      ":ref:`dev-manual/common-tasks:speeding up a build`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`BB_SERVER_TIMEOUT`
@@ -746,7 +746,7 @@
 
       For information on how to use ``BBMULTICONFIG`` in an environment
       that supports building targets with multiple configurations, see the
-      ":ref:`dev-building-images-for-multiple-targets-using-multiple-configurations`"
+      ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configurations`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`BBPATH`
@@ -1002,7 +1002,7 @@
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the build history features to be
       enabled. For more information on how build history works, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+      ":ref:`dev-manual/common-tasks:maintaining build output quality`"
       section in the Yocto Project Development Tasks Manual.
 
       You can specify these features in the form of a space-separated list:
@@ -1016,7 +1016,7 @@
          (SDK).
 
       -  *task:* Save output file signatures for
-         :ref:`shared state <overview-manual/overview-manual-concepts:shared state cache>`
+         :ref:`shared state <overview-manual/concepts:shared state cache>`
          (sstate) tasks.
          This saves one file per task and lists the SHA-256 checksums for
          each file staged (i.e. the output of the task).
@@ -1299,7 +1299,7 @@
       will be the aggregate of all of them.
 
       For information on creating an initramfs, see the
-      ":ref:`building-an-initramfs-image`" section
+      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`CONFIG_SITE`
@@ -1402,7 +1402,7 @@
          newly installed packages to an image, which might be most suitable for
          read-only filesystems that cannot be upgraded. See the
          :term:`LICENSE_CREATE_PACKAGE` variable for additional information.
-         You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+         You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
          section in the Yocto Project Development Tasks Manual for
          information on providing license text.
 
@@ -1418,7 +1418,7 @@
          newly installed packages to an image, which might be most suitable for
          read-only filesystems that cannot be upgraded. See the
          :term:`LICENSE_CREATE_PACKAGE` variable for additional information.
-         You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+         You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
          section in the Yocto Project Development Tasks Manual for
          information on providing license text.
 
@@ -1522,7 +1522,7 @@
       .. note::
 
          Tasks that read from or write to this directory should run under
-         :ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
+         :ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
 
    :term:`DATE`
       The date the build was started. Dates appear using the year, month,
@@ -1641,7 +1641,7 @@
          -  One recipe having another recipe in ``DEPENDS`` does not by
             itself add any runtime dependencies between the packages
             produced by the two recipes. However, as explained in the
-            ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+            ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
             section in the Yocto Project Overview and Concepts Manual,
             runtime dependencies will often be added automatically, meaning
             ``DEPENDS`` alone is sufficient for most recipes.
@@ -1670,11 +1670,11 @@
       ``${TMPDIR}/deploy``.
 
       For more information on the structure of the Build Directory, see
-      ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
+      ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
-      ":ref:`Images <images-dev-environment>`", ":ref:`Package
-      Feeds <package-feeds-dev-environment>`", and
-      ":ref:`sdk-dev-environment`" sections all in the
+      ":ref:`overview-manual/concepts:images`",
+      ":ref:`overview-manual/concepts:package feeds`", and
+      ":ref:`overview-manual/concepts:application development sdk`" sections all in the
       Yocto Project Overview and Concepts Manual.
 
    :term:`DEPLOY_DIR_DEB`
@@ -1695,8 +1695,8 @@
       ``DEPLOY_DIR_DEB`` variable to make sure the
       :ref:`ref-tasks-package_write_deb` task
       writes Debian packages into the appropriate folder. For more
-      information on how packaging works, see the ":ref:`Package
-      Feeds <package-feeds-dev-environment>`" section
+      information on how packaging works, see the
+      ":ref:`overview-manual/concepts:package feeds`" section
       in the Yocto Project Overview and Concepts Manual.
 
    :term:`DEPLOY_DIR_IMAGE`
@@ -1708,10 +1708,10 @@
       ``${DEPLOY_DIR}/images/${MACHINE}/``.
 
       For more information on the structure of the Build Directory, see
-      ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
+      ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
-      ":ref:`Images <images-dev-environment>`" and
-      ":ref:`sdk-dev-environment`" sections both in
+      ":ref:`overview-manual/concepts:images`" and
+      ":ref:`overview-manual/concepts:application development sdk`" sections both in
       the Yocto Project Overview and Concepts Manual.
 
    :term:`DEPLOY_DIR_IPK`
@@ -1731,8 +1731,8 @@
       ``DEPLOY_DIR_IPK`` variable to make sure the
       :ref:`ref-tasks-package_write_ipk` task
       writes IPK packages into the appropriate folder. For more information
-      on how packaging works, see the ":ref:`Package
-      Feeds <package-feeds-dev-environment>`" section
+      on how packaging works, see the
+      ":ref:`overview-manual/concepts:package feeds`" section
       in the Yocto Project Overview and Concepts Manual.
 
    :term:`DEPLOY_DIR_RPM`
@@ -1752,8 +1752,8 @@
       ``DEPLOY_DIR_RPM`` variable to make sure the
       :ref:`ref-tasks-package_write_rpm` task
       writes RPM packages into the appropriate folder. For more information
-      on how packaging works, see the ":ref:`Package
-      Feeds <package-feeds-dev-environment>`" section
+      on how packaging works, see the
+      ":ref:`overview-manual/concepts:package feeds`" section
       in the Yocto Project Overview and Concepts Manual.
 
    :term:`DEPLOY_DIR_TAR`
@@ -1773,8 +1773,8 @@
       ``DEPLOY_DIR_TAR`` variable to make sure the
       :ref:`ref-tasks-package_write_tar` task
       writes TAR packages into the appropriate folder. For more information
-      on how packaging works, see the ":ref:`Package
-      Feeds <package-feeds-dev-environment>`" section
+      on how packaging works, see the
+      ":ref:`overview-manual/concepts:package feeds`" section
       in the Yocto Project Overview and Concepts Manual.
 
    :term:`DEPLOYDIR`
@@ -1997,7 +1997,7 @@
       process gets source files when working behind a firewall or proxy
       server, see this specific question in the ":doc:`faq`"
       chapter. You can also refer to the
-      ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+      ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
       Wiki page.
 
    :term:`DOC_COMPRESS`
@@ -2029,7 +2029,7 @@
       When used with the :ref:`report-error <ref-classes-report-error>`
       class, specifies the path used for storing the debug files created by
       the :ref:`error reporting
-      tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`, which
+      tool <dev-manual/common-tasks:using the error reporting tool>`, which
       allows you to submit build errors you encounter to a central
       database. By default, the value of this variable is
       ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
@@ -2129,7 +2129,7 @@
       For more information on ``externalsrc.bbclass``, see the
       ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
       can also find information on how to use this variable in the
-      ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+      ":ref:`dev-manual/common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`EXTERNALSRC_BUILD`
@@ -2143,7 +2143,7 @@
       For more information on ``externalsrc.bbclass``, see the
       ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
       can also find information on how to use this variable in the
-      ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+      ":ref:`dev-manual/common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`EXTRA_AUTORECONF`
@@ -2181,7 +2181,7 @@
           useful if you want to develop against the libraries in the image.
         - "read-only-rootfs" - Creates an image whose root filesystem is
           read-only. See the
-          ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+          ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
           section in the Yocto Project Development Tasks Manual for more
           information
         - "tools-debug" - Adds debugging tools such as gdb and strace.
@@ -2194,7 +2194,7 @@
       Project, see the ":ref:`ref-features-image`" section.
 
       For an example that shows how to customize your image by using this
-      variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
+      variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`EXTRA_IMAGECMD`
@@ -2419,7 +2419,7 @@
 
       The previous statement appears in the
       ``linux-yocto-dev.bbappend`` file, which is found in the
-      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in
+      :ref:`overview-manual/development-environment:yocto project source repositories` in
       ``meta-intel/common/recipes-kernel/linux``. Here, the machine
       override is a special :term:`PACKAGE_ARCH`
       definition for multiple ``meta-intel`` machines.
@@ -2509,9 +2509,9 @@
       build system uses files from ``files/defconfig``.
 
       You can find out more about the patching process in the
-      ":ref:`patching-dev-environment`" section
+      ":ref:`overview-manual/concepts:patching`" section
       in the Yocto Project Overview and Concepts Manual and the
-      ":ref:`new-recipe-patching-code`" section in
+      ":ref:`dev-manual/common-tasks:patching code`" section in
       the Yocto Project Development Tasks Manual. See the
       :ref:`ref-tasks-patch` task as well.
 
@@ -2904,10 +2904,10 @@
       the same files into a ``boot`` directory within the target partition.
 
       You can find information on how to use the Wic tool in the
-      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+      ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
       section of the Yocto Project Development Tasks Manual. Reference
       material for Wic is located in the
-      ":doc:`../ref-manual/ref-kickstart`" chapter.
+      ":doc:`/ref-manual/kickstart`" chapter.
 
    :term:`IMAGE_BOOT_FILES`
       A space-separated list of files installed into the boot partition
@@ -2940,10 +2940,10 @@
       the same files into a ``boot`` directory within the target partition.
 
       You can find information on how to use the Wic tool in the
-      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+      ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
       section of the Yocto Project Development Tasks Manual. Reference
       material for Wic is located in the
-      ":doc:`../ref-manual/ref-kickstart`" chapter.
+      ":doc:`/ref-manual/kickstart`" chapter.
 
    :term:`IMAGE_CLASSES`
       A list of classes that all images should inherit. You typically use
@@ -3000,7 +3000,7 @@
       the ":ref:`ref-features-image`" section.
 
       For an example that shows how to customize your image by using this
-      variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
+      variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`IMAGE_FSTYPES`
@@ -3051,18 +3051,18 @@
       .. note::
 
          -  When working with a
-            :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
+            :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
             image, do not use the ``IMAGE_INSTALL`` variable to specify
             packages for installation. Instead, use the
             :term:`PACKAGE_INSTALL` variable, which
             allows the initial RAM filesystem (initramfs) recipe to use a
             fixed set of packages and not be affected by ``IMAGE_INSTALL``.
             For information on creating an initramfs, see the
-            ":ref:`building-an-initramfs-image`"
+            ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
             section in the Yocto Project Development Tasks Manual.
 
          -  Using ``IMAGE_INSTALL`` with the
-            :ref:`+= <bitbake:appending-and-prepending>`
+            :ref:`+= <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending (+=) and prepending (=+) with spaces>`
             BitBake operator within the ``/conf/local.conf`` file or from
             within an image recipe is not recommended. Use of this operator
             in these ways can cause ordering issues. Since
@@ -3126,7 +3126,7 @@
       The location is
       derived using the :term:`DEPLOY_DIR_IMAGE`
       and :term:`IMAGE_NAME` variables. You can find
-      information on how the image is created in the ":ref:`image-generation-dev-environment`"
+      information on how the image is created in the ":ref:`overview-manual/concepts:image generation`"
       section in the Yocto Project Overview and Concepts Manual.
 
    :term:`IMAGE_NAME`
@@ -3554,7 +3554,7 @@
       :term:`INITRAMFS_IMAGE_BUNDLE`
       variable, which allows the generated image to be bundled inside the
       kernel image. Additionally, for information on creating an initramfs
-      image, see the ":ref:`building-an-initramfs-image`" section
+      image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`INITRAMFS_IMAGE_BUNDLE`
@@ -3600,9 +3600,9 @@
          configuration file. You cannot set the variable in a recipe file.
 
       See the
-      :yocto_git:`local.conf.sample.extended </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended>`
+      :yocto_git:`local.conf.sample.extended </poky/tree/meta-poky/conf/local.conf.sample.extended>`
       file for additional information. Also, for information on creating an
-      initramfs, see the ":ref:`building-an-initramfs-image`" section
+      initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`INITRAMFS_LINK_NAME`
@@ -3723,7 +3723,7 @@
       - qemu
       - mips
 
-      You define the ``KARCH`` variable in the :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`.
+      You define the ``KARCH`` variable in the :ref:`kernel-dev/advanced:bsp descriptions`.
 
    :term:`KBRANCH`
       A regular expression used by the build process to explicitly identify
@@ -3793,7 +3793,7 @@
 
       For more
       information on how to use the ``KBUILD_DEFCONFIG`` variable, see the
-      ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`"
+      ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`"
       section in the Yocto Project Linux Kernel Development Manual.
 
    :term:`KERNEL_ALT_IMAGETYPE`
@@ -4029,7 +4029,7 @@
       of the :term:`STAGING_KERNEL_DIR` within
       the :ref:`module <ref-classes-module>` class. For information on
       how this variable is used, see the
-      ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+      ":ref:`kernel-dev/common:incorporating out-of-tree modules`"
       section in the Yocto Project Linux Kernel Development Manual.
 
       To help maximize compatibility with out-of-tree drivers used to build
@@ -4043,7 +4043,7 @@
       of the :term:`STAGING_KERNEL_DIR` within
       the :ref:`module <ref-classes-module>` class. For information on
       how this variable is used, see the
-      ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+      ":ref:`kernel-dev/common:incorporating out-of-tree modules`"
       section in the Yocto Project Linux Kernel Development Manual.
 
       To help maximize compatibility with out-of-tree drivers used to build
@@ -4108,13 +4108,13 @@
    :term:`KTYPE`
       Defines the kernel type to be used in assembling the configuration.
       The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
-      kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+      kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
       section in the
       Yocto Project Linux Kernel Development Manual for more information on
       kernel types.
 
       You define the ``KTYPE`` variable in the
-      :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. The
+      :ref:`kernel-dev/advanced:bsp descriptions`. The
       value you use must match the value used for the
       :term:`LINUX_KERNEL_TYPE` value used by the
       kernel recipe.
@@ -4177,7 +4177,7 @@
       To specify the OE-Core versions for which a layer is compatible, use
       this variable in your layer's ``conf/layer.conf`` configuration file.
       For the list, use the Yocto Project
-      :yocto_wiki:`Release Name </wiki/Releases>` (e.g.
+      :yocto_wiki:`Release Name </Releases>` (e.g.
       DISTRO_NAME_NO_CAP). To specify multiple OE-Core versions for the
       layer, use a space-separated list:
       ::
@@ -4191,7 +4191,7 @@
          The OpenEmbedded build system produces a warning if the variable
          is not set for any given layer.
 
-      See the ":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+      See the ":ref:`dev-manual/common-tasks:creating your own layer`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LAYERVERSION`
@@ -4240,7 +4240,7 @@
       This variable must be defined for all recipes (unless
       :term:`LICENSE` is set to "CLOSED").
 
-      For more information, see the ":ref:`usingpoky-configuring-lic_files_chksum`"
+      For more information, see the ":ref:`dev-manual/common-tasks:tracking license changes`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LICENSE`
@@ -4306,7 +4306,7 @@
       For related information on providing license text, see the
       :term:`COPY_LIC_DIRS` variable, the
       :term:`COPY_LIC_MANIFEST` variable, and the
-      ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+      ":ref:`dev-manual/common-tasks:providing license text`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LICENSE_FLAGS`
@@ -4319,7 +4319,7 @@
       typically used to mark recipes that might require additional licenses
       in order to be used in a commercial product. For more information,
       see the
-      ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+      ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LICENSE_FLAGS_WHITELIST`
@@ -4327,7 +4327,7 @@
       :term:`LICENSE_FLAGS` within a recipe should not
       prevent that recipe from being built. This practice is otherwise
       known as "whitelisting" license flags. For more information, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+      ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LICENSE_PATH`
@@ -4343,7 +4343,7 @@
    :term:`LINUX_KERNEL_TYPE`
       Defines the kernel type to be used in assembling the configuration.
       The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
-      kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+      kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
       section in the
       Yocto Project Linux Kernel Development Manual for more information on
       kernel types.
@@ -4890,7 +4890,7 @@
       Controls how the OpenEmbedded build system spawns interactive
       terminals on the host development system (e.g. using the BitBake
       command with the ``-c devshell`` command-line option). For more
-      information, see the ":ref:`platdev-appdev-devshell`" section in
+      information, see the ":ref:`dev-manual/common-tasks:using a development shell`" section in
       the Yocto Project Development Tasks Manual.
 
       You can use the following values for the ``OE_TERMINAL`` variable:
@@ -4959,7 +4959,7 @@
 
          An easy way to see what overrides apply is to search for ``OVERRIDES``
          in the output of the ``bitbake -e`` command. See the
-         ":ref:`dev-debugging-viewing-variable-values`" section in the Yocto
+         ":ref:`dev-manual/common-tasks:viewing variable values`" section in the Yocto
          Project Development Tasks Manual for more information.
 
    :term:`P`
@@ -4981,7 +4981,7 @@
       specific by using the package name as a suffix.
 
       You can find out more about applying this variable in the
-      ":ref:`dev-manual/dev-manual-common-tasks:adding custom metadata to packages`"
+      ":ref:`dev-manual/common-tasks:adding custom metadata to packages`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGE_ARCH`
@@ -5079,7 +5079,7 @@
          separate ``*-src`` pkg. This is the default behavior.
 
       You can find out more about debugging using GDB by reading the
-      ":ref:`platdev-gdb-remotedebug`" section
+      ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGE_EXCLUDE_COMPLEMENTARY`
@@ -5240,10 +5240,10 @@
       general, you should use the
       :term:`IMAGE_INSTALL` variable to specify
       packages for installation. The exception to this is when working with
-      the :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
+      the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
       image. When working with an initial RAM filesystem (initramfs) image,
       use the ``PACKAGE_INSTALL`` variable. For information on creating an
-      initramfs, see the ":ref:`building-an-initramfs-image`" section
+      initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGE_INSTALL_ATTEMPTONLY`
@@ -5266,7 +5266,7 @@
       ``PACKAGE_WRITE_DEPS``.
 
       For information on running post-installation scripts, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+      ":ref:`dev-manual/common-tasks:post-installation scripts`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGECONFIG`
@@ -5423,7 +5423,7 @@
 
       For an example of how to use the ``PACKAGES_DYNAMIC`` variable when
       you are splitting packages, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:handling optional module packaging`"
+      ":ref:`dev-manual/common-tasks:handling optional module packaging`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGESPLITFUNCS`
@@ -5458,7 +5458,7 @@
          the ``do_compile`` task that result in race conditions, you can clear
          the ``PARALLEL_MAKE`` variable within the recipe as a workaround. For
          information on addressing race conditions, see the
-         ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+         ":ref:`dev-manual/common-tasks:debugging parallel make races`"
          section in the Yocto Project Development Tasks Manual.
 
       For single socket systems (i.e. one CPU), you should not have to
@@ -5468,7 +5468,7 @@
       not set higher than "-j 20".
 
       For more information on speeding up builds, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+      ":ref:`dev-manual/common-tasks:speeding up a build`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`PARALLEL_MAKEINST`
@@ -5488,7 +5488,7 @@
          the ``do_install`` task that result in race conditions, you can
          clear the ``PARALLEL_MAKEINST`` variable within the recipe as a
          workaround. For information on addressing race conditions, see the
-         ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+         ":ref:`dev-manual/common-tasks:debugging parallel make races`"
          section in the Yocto Project Development Tasks Manual.
 
    :term:`PATCHRESOLVE`
@@ -5578,9 +5578,9 @@
          ${STAGING_DIR_HOST}/pkgdata
 
       For examples of how this data is used, see the
-      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+      ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual and the
-      ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
+      ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
       section in the Yocto Project Development Tasks Manual. For more
       information on the shared, global-state directory, see
       :term:`STAGING_DIR_HOST`.
@@ -5691,9 +5691,9 @@
 
          The OpenEmbedded build system does not need the aid of ``PR``
          to know when to rebuild a recipe. The build system uses the task
-         :ref:`input checksums <overview-checksums>` along with the
+         :ref:`input checksums <overview-manual/concepts:checksums (signatures)>` along with the
          :ref:`stamp <structure-build-tmp-stamps>` and
-         :ref:`overview-manual/overview-manual-concepts:shared state cache`
+         :ref:`overview-manual/concepts:shared state cache`
          mechanisms.
 
       The ``PR`` variable primarily becomes significant when a package
@@ -5713,7 +5713,7 @@
 
       Because manually managing ``PR`` can be cumbersome and error-prone,
       an automated solution exists. See the
-      ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" section
+      ":ref:`dev-manual/common-tasks:working with a pr service`" section
       in the Yocto Project Development Tasks Manual for more information.
 
    :term:`PREFERRED_PROVIDER`
@@ -5738,7 +5738,7 @@
          PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
 
       For more
-      information, see the ":ref:`metadata-virtual-providers`"
+      information, see the ":ref:`dev-manual/common-tasks:using virtual providers`"
       section in the Yocto Project Development Tasks Manual.
 
       .. note::
@@ -5875,7 +5875,7 @@
                          libplds4.so"
 
       For more information, see the
-      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+      ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual.
 
    :term:`PROVIDES`
@@ -5951,7 +5951,7 @@
 
       You must
       set the variable if you want to automatically start a local :ref:`PR
-      service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
+      service <dev-manual/common-tasks:working with a pr service>`. You can
       set ``PRSERV_HOST`` to other values to use a remote PR service.
 
 
@@ -5965,7 +5965,7 @@
 
    :term:`PTEST_ENABLED`
       Specifies whether or not :ref:`Package
-      Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
+      Test <dev-manual/common-tasks:testing packages with ptest>` (ptest)
       functionality is enabled when building a recipe. You should not set
       this variable directly. Enabling and disabling building Package Tests
       at build time should be done by adding "ptest" to (or removing it
@@ -6068,7 +6068,7 @@
       runtime dependencies are automatically detected and added. Therefore,
       most recipes do not need to set ``RDEPENDS``. For more information,
       see the
-      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+      ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual.
 
       The practical effect of the above ``RDEPENDS`` assignment is that
@@ -6542,7 +6542,7 @@
 
       For additional information on how to customize the extensible SDK's
       configuration, see the
-      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+      ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
@@ -6568,7 +6568,7 @@
 
       For additional information on how to customize the extensible SDK's
       configuration, see the
-      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+      ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
@@ -6587,7 +6587,7 @@
 
       For additional information on how to customize the extensible SDK's
       configuration, see the
-      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+      ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
@@ -6710,7 +6710,7 @@
       ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
 
       For information on how to change this default title, see the
-      ":ref:`sdk-manual/sdk-appendix-customizing:changing the extensible sdk installer title`"
+      ":ref:`sdk-manual/appendix-customizing:changing the extensible sdk installer title`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
@@ -6748,7 +6748,7 @@
       default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
 
       For information on how to change this default directory, see the
-      ":ref:`sdk-manual/sdk-appendix-customizing:changing the default sdk installation directory`"
+      ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
@@ -7000,7 +7000,7 @@
       various ``SPL_*`` variables used by the OpenEmbedded build system.
 
       See the BeagleBone machine configuration example in the
-      ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+      ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
       section in the Yocto Project Board Support Package Developer's Guide
       for additional information.
 
@@ -7018,12 +7018,12 @@
       protocols are highly dependent on particular BitBake Fetcher
       submodules. Depending on the fetcher BitBake uses, various URL
       parameters are employed. For specifics on the supported Fetchers, see
-      the ":ref:`Fetchers <bitbake:bb-fetchers>`" section in the
+      the ":ref:`Fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`" section in the
       BitBake User Manual.
 
       -  ``file://`` - Fetches files, which are usually files shipped
          with the :term:`Metadata`, from the local machine (e.g.
-         :ref:`patch <patching-dev-environment>` files).
+         :ref:`patch <overview-manual/concepts:patching>` files).
          The path is relative to the :term:`FILESPATH`
          variable. Thus, the build system searches, in order, from the
          following directories, which are assumed to be a subdirectories of
@@ -7200,7 +7200,7 @@
          For information on limitations when inheriting the latest revision
          of software using ``SRCREV``, see the :term:`AUTOREV` variable
          description and the
-         ":ref:`automatically-incrementing-a-binary-package-revision-number`"
+         ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
          section, which is in the Yocto Project Development Tasks Manual.
 
    :term:`SSTATE_DIR`
@@ -7314,9 +7314,9 @@
 
       For information on how staging for recipe-specific sysroots occurs,
       see the :ref:`ref-tasks-populate_sysroot`
-      task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`"
+      task, the ":ref:`sdk-manual/extensible:sharing files between recipes`"
       section in the Yocto Project Development Tasks Manual, the
-      ":ref:`configuration-compilation-and-staging-dev-environment`"
+      ":ref:`overview-manual/concepts:configuration, compilation, and staging`"
       section in the Yocto Project Overview and Concepts Manual, and the
       :term:`SYSROOT_DIRS` variable.
 
@@ -7437,7 +7437,7 @@
 
       For information on how BitBake uses stamp files to determine if a
       task should be rerun, see the
-      ":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+      ":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
       section in the Yocto Project Overview and Concepts Manual.
 
       See :term:`STAMPS_DIR`,
@@ -7660,7 +7660,7 @@
 
    :term:`SYSVINIT_ENABLED_GETTYS`
       When using
-      :ref:`SysVinit <dev-manual/dev-manual-common-tasks:enabling system services>`,
+      :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
       specifies a space-separated list of the virtual terminals that should
       run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
       (allowing login), assuming :term:`USE_VT` is not set to
@@ -7946,7 +7946,7 @@
       file.
 
       For more information on testing images, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+      ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`TEST_SERIALCONTROL_CMD`
@@ -8022,7 +8022,7 @@
          TEST_SUITES = "test_A test_B"
 
       For more information on testing images, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+      ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`TEST_TARGET`
@@ -8042,7 +8042,7 @@
       You can provide the following arguments with ``TEST_TARGET``:
 
       -  *"qemu":* Boots a QEMU image and runs the tests. See the
-         ":ref:`qemu-image-enabling-tests`" section
+         ":ref:`dev-manual/common-tasks:enabling runtime tests on qemu`" section
          in the Yocto Project Development Tasks Manual for more
          information.
 
@@ -8058,7 +8058,7 @@
             ``meta/lib/oeqa/controllers/simpleremote.py``.
 
       For information on running tests on hardware, see the
-      ":ref:`hardware-image-enabling-tests`"
+      ":ref:`dev-manual/common-tasks:enabling runtime tests on hardware`"
       section in the Yocto Project Development Tasks Manual.
 
    :term:`TEST_TARGET_IP`
@@ -8096,7 +8096,7 @@
 
       For more information
       on enabling, running, and writing these tests, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+      ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual and the
       ":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
 
@@ -8145,16 +8145,16 @@
       In this case, a default list of packages is
       set in this variable, but you can add additional packages to the
       list. See the
-      ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
+      ":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" section
       in the Yocto Project Application Development and the Extensible
       Software Development Kit (eSDK) manual for more information.
 
       For background information on cross-development toolchains in the
       Yocto Project development environment, see the
-      ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
+      ":ref:`sdk-manual/intro:the cross-development toolchain`"
       section in the Yocto Project Overview and Concepts Manual. For
       information on setting up a cross-development environment, see the
-      :doc:`../sdk-manual/sdk-manual` manual.
+      :doc:`/sdk-manual/index` manual.
 
    :term:`TOOLCHAIN_OUTPUTNAME`
       This variable defines the name used for the toolchain output. The
@@ -8175,16 +8175,16 @@
       target hardware), which includes libraries and headers. Use this
       variable to add individual packages to the part of the SDK that runs
       on the target. See the
-      ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
+      ":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" section
       in the Yocto Project Application Development and the Extensible
       Software Development Kit (eSDK) manual for more information.
 
       For background information on cross-development toolchains in the
       Yocto Project development environment, see the
-      ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
+      ":ref:`sdk-manual/intro:the cross-development toolchain`"
       section in the Yocto Project Overview and Concepts Manual. For
       information on setting up a cross-development environment, see the
-      :doc:`../sdk-manual/sdk-manual` manual.
+      :doc:`/sdk-manual/index` manual.
 
    :term:`TOPDIR`
       The top-level :term:`Build Directory`. BitBake
@@ -8554,13 +8554,13 @@
       specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a
       statically populated ``/dev`` directory.
 
-      See the ":ref:`selecting-dev-manager`" section in
+      See the ":ref:`dev-manual/common-tasks:selecting a device manager`" section in
       the Yocto Project Development Tasks Manual for information on how to
       use this variable.
 
    :term:`USE_VT`
       When using
-      :ref:`SysVinit <new-recipe-enabling-system-services>`,
+      :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
       determines whether or not to run a
       `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
       virtual terminals in order to enable logging in through those
@@ -8735,9 +8735,9 @@
       OpenEmbedded build system to create a partitioned image
       (image\ ``.wic``). For information on how to create a partitioned
       image, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+      ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
       section in the Yocto Project Development Tasks Manual. For details on
-      the kickstart file format, see the ":doc:`../ref-manual/ref-kickstart`" Chapter.
+      the kickstart file format, see the ":doc:`/ref-manual/kickstart`" Chapter.
 
    :term:`WKS_FILE_DEPENDS`
       When placed in the recipe that builds your image, this variable lists
diff --git a/poky/documentation/ref-manual/ref-varlocality.rst b/poky/documentation/ref-manual/varlocality.rst
similarity index 100%
rename from poky/documentation/ref-manual/ref-varlocality.rst
rename to poky/documentation/ref-manual/varlocality.rst
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index 9992f97..2546300 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -4,6 +4,12 @@
  Current Release Manuals
 =========================
 
+*******************************
+3.2 'gatesgarth' Release Series
+*******************************
+
+- :yocto_docs:`3.2 Documentation </3.2>`
+
 ****************************
 3.1 'dunfell' Release Series
 ****************************
@@ -12,6 +18,7 @@
 - :yocto_docs:`3.1.1 Documentation </3.1.1>`
 - :yocto_docs:`3.1.2 Documentation </3.1.2>`
 - :yocto_docs:`3.1.3 Documentation </3.1.3>`
+- :yocto_docs:`3.1.4 Documentation </3.1.4>`
 
 ==========================
  Previous Release Manuals
diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.rst b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
similarity index 100%
rename from poky/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
rename to poky/documentation/sdk-manual/appendix-customizing-standard.rst
diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
similarity index 99%
rename from poky/documentation/sdk-manual/sdk-appendix-customizing.rst
rename to poky/documentation/sdk-manual/appendix-customizing.rst
index 5a33f63..97ade08 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -87,7 +87,7 @@
    following:
 
    -  After ensuring the tasks are :ref:`shared
-      state <overview-manual/overview-manual-concepts:shared state cache>` tasks (i.e. the
+      state <overview-manual/concepts:shared state cache>` tasks (i.e. the
       output of the task is saved to and can be restored from the shared
       state cache) or ensuring the tasks are able to be produced quickly
       from a task that is a shared state task, add the task name to the
diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
similarity index 95%
rename from poky/documentation/sdk-manual/sdk-appendix-obtain.rst
rename to poky/documentation/sdk-manual/appendix-obtain.rst
index eef425b..cdfe2cc 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -15,7 +15,7 @@
 Follow these steps to locate and hand-install the toolchain:
 
 1. *Go to the Installers Directory:* Go to
-   :yocto_dl:`/releases/yocto/yocto-3.1.2/toolchain/`
+   :yocto_dl:`/releases/yocto/yocto-&DISTRO;/toolchain/`
 
 2. *Open the Folder for Your Build Host:* Open the folder that matches
    your :term:`Build Host` (i.e.
@@ -81,7 +81,7 @@
 build the SDK installer. Follow these steps:
 
 1. *Set Up the Build Environment:* Be sure you are set up to use BitBake
-   in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`" section
+   in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
    in the Yocto Project Development Tasks Manual for information on how
    to get a build host ready that is either a native Linux machine or a
    machine that uses CROPS.
@@ -89,9 +89,9 @@
 2. *Clone the ``poky`` Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory`
    (i.e. a local
-   ``poky`` repository). See the ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and
-   possibly the ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
-   ":ref:`checkout-out-by-tag-in-poky`" sections
+   ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
+   possibly the ":ref:`dev-manual/start:checking out by branch in poky`" and
+   ":ref:`dev-manual/start:checking out by tag in poky`" sections
    all in the Yocto Project Development Tasks Manual for information on
    how to clone the ``poky`` repository and check out the appropriate
    branch for your work.
@@ -202,7 +202,7 @@
    Image File:* You need to find and download the root filesystem image
    file that is appropriate for your target system. These files are kept
    in machine-specific folders in the
-   :yocto_dl:`Index of Releases </releases/yocto/yocto-3.1.2/machines/>`
+   :yocto_dl:`Index of Releases </releases/yocto/yocto-&DISTRO;/machines/>`
    in the "machines" directory.
 
    The machine-specific folders of the "machines" directory contain
@@ -246,7 +246,7 @@
    installed the toolchain (e.g. ``poky_sdk``).
 
    Following is an example based on the toolchain installed in the
-   ":ref:`sdk-manual/sdk-appendix-obtain:locating pre-built sdk installers`" section:
+   ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section:
    ::
 
       $ source ~/poky_sdk/environment-setup-core2-64-poky-linux
@@ -256,7 +256,7 @@
 
    Following is an example command that extracts the root filesystem
    from a previously built root filesystem image that was downloaded
-   from the :yocto_dl:`Index of Releases </releases/yocto/yocto-3.1.2/machines/>`.
+   from the :yocto_dl:`Index of Releases </releases/yocto/yocto-&DISTRO;/machines/>`.
    This command extracts the root filesystem into the ``core2-64-sato``
    directory:
    ::
@@ -285,7 +285,7 @@
 portions of the file or directory name. For example, install_dir/version
 is the directory where the SDK is installed. By default, this directory
 is ``/opt/poky/``. And, version represents the specific snapshot of the
-SDK (e.g. 3.1.2). Furthermore, target represents the target architecture
+SDK (e.g. &DISTRO;). Furthermore, target represents the target architecture
 (e.g. ``i586``) and host represents the development system's
 architecture (e.g. ``x86_64``). Thus, the complete names of the two
 directories within the ``sysroots`` could be ``i586-poky-linux`` and
diff --git a/poky/documentation/sdk-manual/sdk-extensible.rst b/poky/documentation/sdk-manual/extensible.rst
similarity index 99%
rename from poky/documentation/sdk-manual/sdk-extensible.rst
rename to poky/documentation/sdk-manual/extensible.rst
index 10e4d20..c94213d 100644
--- a/poky/documentation/sdk-manual/sdk-extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -47,7 +47,7 @@
 You can download a tarball installer, which includes the pre-built
 toolchain, the ``runqemu`` script, the internal build system,
 ``devtool``, and support files from the appropriate
-:yocto_dl:`toolchain </releases/yocto/yocto-3.1.2/toolchain/>` directory within the Index of
+:yocto_dl:`toolchain </releases/yocto/yocto-&DISTRO;/toolchain/>` directory within the Index of
 Releases. Toolchains are available for several 32-bit and 64-bit
 architectures with the ``x86_64`` directories, respectively. The
 toolchains the Yocto Project provides are based off the
@@ -78,7 +78,7 @@
 
        release_version is a string representing the release number of the Yocto Project:
 
-                  3.1.2, 3.1.2+snapshot
+                  &DISTRO;, &DISTRO;+snapshot
 
 For example, the following SDK installer is for a 64-bit
 development host system and a i586-tuned target architecture based off
@@ -183,7 +183,7 @@
    part of an image built using the build system.
 
 The ``devtool`` command line is organized similarly to
-:ref:`overview-manual/overview-manual-development-environment:git` in that it has a number of
+:ref:`overview-manual/development-environment:git` in that it has a number of
 sub-commands for each function. You can run ``devtool --help`` to see
 all the commands.
 
@@ -627,7 +627,7 @@
 or out of the ``devtool``
 :ref:`devtool-the-workspace-layer-structure`,
 and work with any source file forms that the
-:ref:`fetchers <bitbake:bb-fetchers>` support.
+:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` support.
 
 The following diagram shows the common development flow used with the
 ``devtool upgrade`` command:
diff --git a/poky/documentation/sdk-manual/sdk-manual.rst b/poky/documentation/sdk-manual/index.rst
similarity index 72%
rename from poky/documentation/sdk-manual/sdk-manual.rst
rename to poky/documentation/sdk-manual/index.rst
index 177826e..fce2b19 100644
--- a/poky/documentation/sdk-manual/sdk-manual.rst
+++ b/poky/documentation/sdk-manual/index.rst
@@ -10,13 +10,13 @@
    :caption: Table of Contents
    :numbered:
 
-   sdk-intro
-   sdk-extensible
-   sdk-using
-   sdk-working-projects
-   sdk-appendix-obtain
-   sdk-appendix-customizing
-   sdk-appendix-customizing-standard
+   intro
+   extensible
+   using
+   working-projects
+   appendix-obtain
+   appendix-customizing
+   appendix-customizing-standard
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/sdk-manual/sdk-intro.rst b/poky/documentation/sdk-manual/intro.rst
similarity index 97%
rename from poky/documentation/sdk-manual/sdk-intro.rst
rename to poky/documentation/sdk-manual/intro.rst
index ca6138c..66b12cd 100644
--- a/poky/documentation/sdk-manual/sdk-intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -184,7 +184,7 @@
    root filesystem images.
 
    If you are going to develop your application on hardware, go to the
-   :yocto_dl:`machines </releases/yocto/yocto-3.1.2/machines/>` download area and choose a
+   :yocto_dl:`machines </releases/yocto/yocto-&DISTRO;/machines/>` download area and choose a
    target machine area from which to download the kernel image and root
    filesystem. This download area could have several files in it that
    support development using actual hardware. For example, the area
@@ -194,7 +194,7 @@
 
    If you are going to develop your application and then run and test it
    using the QEMU emulator, go to the
-   :yocto_dl:`machines/qemu </releases/yocto/yocto-3.1.2/machines/qemu>` download area. From this
+   :yocto_dl:`machines/qemu </releases/yocto/yocto-&DISTRO;/machines/qemu>` download area. From this
    area, go down into the directory for your target architecture (e.g.
    ``qemux86_64`` for an Intel-based 64-bit architecture). Download the
    kernel, root filesystem, and any other files you need for your
@@ -211,7 +211,7 @@
    tools to develop your application. If you need to separately install
    and use the QEMU emulator, you can go to `QEMU Home
    Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
-   the emulator. See the ":doc:`../dev-manual/dev-manual-qemu`" chapter in the
+   the emulator. See the ":doc:`/dev-manual/qemu`" chapter in the
    Yocto Project Development Tasks Manual for information on using QEMU
    within the Yocto Project.
 
diff --git a/poky/documentation/sdk-manual/sdk-using.rst b/poky/documentation/sdk-manual/using.rst
similarity index 91%
rename from poky/documentation/sdk-manual/sdk-using.rst
rename to poky/documentation/sdk-manual/using.rst
index 3a1cae7..29fb504 100644
--- a/poky/documentation/sdk-manual/sdk-using.rst
+++ b/poky/documentation/sdk-manual/using.rst
@@ -43,7 +43,7 @@
 
 You can download a tarball installer, which includes the pre-built
 toolchain, the ``runqemu`` script, and support files from the
-appropriate :yocto_dl:`toolchain </releases/yocto/yocto-3.1.2/toolchain/>` directory within
+appropriate :yocto_dl:`toolchain </releases/yocto/yocto-&DISTRO;/toolchain/>` directory within
 the Index of Releases. Toolchains are available for several 32-bit and
 64-bit architectures with the ``x86_64`` directories, respectively. The
 toolchains the Yocto Project provides are based off the
@@ -72,7 +72,7 @@
 
        release_version is a string representing the release number of the Yocto Project:
 
-                  3.1.2, 3.1.2+snapshot
+                  &DISTRO;, &DISTRO;+snapshot
 
 For example, the following SDK installer is for a 64-bit
 development host system and a i586-tuned target architecture based off
@@ -109,16 +109,16 @@
 
 ::
 
-   $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-3.1.2.sh
-   Poky (Yocto Project Reference Distro) SDK installer version 3.1.2
+   $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+   Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
    ===============================================================
-   Enter target directory for SDK (default: /opt/poky/3.1.2):
-   You are about to install the SDK to "/opt/poky/3.1.2". Proceed [Y/n]? Y
+   Enter target directory for SDK (default: /opt/poky/&DISTRO;):
+   You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed [Y/n]? Y
    Extracting SDK........................................ ..............................done
    Setting it up...done
    SDK has been successfully set up and is ready to be used.
    Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
-    $ . /opt/poky/3.1.2/environment-setup-i586-poky-linux
+    $ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
 Again, reference the "`Installed Standard SDK Directory
 Structure <#sdk-installed-standard-sdk-directory-structure>`__" section
@@ -131,7 +131,7 @@
 Once you have the SDK installed, you must run the SDK environment setup
 script before you can actually use the SDK. This setup script resides in
 the directory you chose when you installed the SDK, which is either the
-default ``/opt/poky/3.1.2`` directory or the directory you chose during
+default ``/opt/poky/&DISTRO;`` directory or the directory you chose during
 installation.
 
 Before running the script, be sure it is the one that matches the
@@ -143,7 +143,7 @@
 script is for an IA-based target machine using i586 tuning:
 ::
 
-   $ source /opt/poky/3.1.2/environment-setup-i586-poky-linux
+   $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
 When you run the
 setup script, the same environment variables are defined as are when you
diff --git a/poky/documentation/sdk-manual/sdk-working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst
similarity index 96%
rename from poky/documentation/sdk-manual/sdk-working-projects.rst
rename to poky/documentation/sdk-manual/working-projects.rst
index 5c828fd..3e40936 100644
--- a/poky/documentation/sdk-manual/sdk-working-projects.rst
+++ b/poky/documentation/sdk-manual/working-projects.rst
@@ -10,7 +10,7 @@
 Autotools-Based Projects
 ========================
 
-Once you have a suitable :ref:`sdk-manual/sdk-intro:the cross-development toolchain`
+Once you have a suitable :ref:`sdk-manual/intro:the cross-development toolchain`
 installed, it is very easy to develop a project using the `GNU
 Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__
 workflow, which is outside of the :term:`OpenEmbedded Build System`.
@@ -86,11 +86,11 @@
    the string "environment-setup" and contains the machine architecture,
    which is followed by the string "poky-linux". For this example, the
    command sources a script from the default SDK installation directory
-   that uses the 32-bit Intel x86 Architecture and the 3.1.2 Yocto
+   that uses the 32-bit Intel x86 Architecture and the &DISTRO; Yocto
    Project release:
    ::
 
-      $ source /opt/poky/3.1.2/environment-setup-i586-poky-linux
+      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
 3. *Create the configure Script:* Use the ``autoreconf`` command to
    generate the ``configure`` script.
@@ -229,14 +229,14 @@
 
 Running the
 SDK setup script for a 64-bit build host and an i586-tuned target
-architecture for a ``core-image-sato`` image using the current 3.1.2
+architecture for a ``core-image-sato`` image using the current &DISTRO;
 Yocto Project release and then echoing that variable shows the value
 established through the script:
 ::
 
-   $ source /opt/poky/3.1.2/environment-setup-i586-poky-linux
+   $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
    $ echo ${CC}
-   i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/3.1.2/sysroots/i586-poky-linux
+   i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/&DISTRO;/sysroots/i586-poky-linux
 
 To illustrate variable use, work through this simple "Hello World!"
 example:
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index fe9841b..fc901d3 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -4,7 +4,7 @@
   var all_versions = {
     'dev': 'dev (3.3)',
     '3.2': '3.2',
-    '3.1.3': '3.1.3',
+    '3.1.4': '3.1.4',
     '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',
   };
diff --git a/poky/documentation/test-manual/test-manual.rst b/poky/documentation/test-manual/index.rst
similarity index 75%
rename from poky/documentation/test-manual/test-manual.rst
rename to poky/documentation/test-manual/index.rst
index 2891f06..e2198c4 100644
--- a/poky/documentation/test-manual/test-manual.rst
+++ b/poky/documentation/test-manual/index.rst
@@ -10,9 +10,9 @@
    :caption: Table of Contents
    :numbered:
 
-   test-manual-intro
-   test-manual-test-process
-   test-manual-understand-autobuilder
+   intro
+   test-process
+   understand-autobuilder
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/test-manual/test-manual-intro.rst b/poky/documentation/test-manual/intro.rst
similarity index 96%
rename from poky/documentation/test-manual/test-manual-intro.rst
rename to poky/documentation/test-manual/intro.rst
index b6d1305..81c24a8 100644
--- a/poky/documentation/test-manual/test-manual-intro.rst
+++ b/poky/documentation/test-manual/intro.rst
@@ -25,14 +25,14 @@
 engineers:
 
 -  *yocto-autobuilder2:* This
-   :yocto_git:`README.md </cgit.cgi/yocto-autobuilder2/tree/README.md>`
+   :yocto_git:`README.md </yocto-autobuilder2/tree/README.md>`
    is the main README which detials how to set up the Yocto Project
    Autobuilder. The ``yocto-autobuilder2`` repository represents the
    Yocto Project's console UI plugin to Buildbot and the configuration
    necessary to configure Buildbot to perform the testing the project
    requires.
 
--  *yocto-autobuilder-helper:* This :yocto_git:`README </cgit.cgi/yocto-autobuilder-helper/tree/README/>`
+-  *yocto-autobuilder-helper:* This :yocto_git:`README </yocto-autobuilder-helper/tree/README/>`
    and repository contains Yocto Project Autobuilder Helper scripts and
    configuration. The ``yocto-autobuilder-helper`` repository contains
    the "glue" logic that defines which tests to run and how to run them.
@@ -124,7 +124,7 @@
    The tests utilize the ``testsdkext`` class and the ``do_testsdkext`` task.
 
 -  *Feature Testing:* Various scenario-based tests are run through the
-   :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/ref-release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions
+   :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions
    we support.
 
 -  *Image Testing:* Image tests initiated through the following command::
@@ -142,9 +142,9 @@
 -  *Package Testing:* A Package Test (ptest) runs tests against packages
    built by the OpenEmbedded build system on the target machine. See the
    :ref:`Testing Packages With
-   ptest <dev-manual/dev-manual-common-tasks:Testing Packages With ptest>` section
+   ptest <dev-manual/common-tasks:Testing Packages With ptest>` section
    in the Yocto Project Development Tasks Manual and the
-   ":yocto_wiki:`Ptest </wiki/Ptest>`" Wiki page for more
+   ":yocto_wiki:`Ptest </Ptest>`" Wiki page for more
    information on Ptest.
 
 -  *SDK Testing:* Image tests initiated through the following command::
@@ -155,8 +155,8 @@
    the ``do_testsdk`` task.
 
 -  *Unit Testing:* Unit tests on various components of the system run
-   through :ref:`bitbake-selftest <ref-manual/ref-release-process:Testing and Quality Assurance>` and
-   :ref:`oe-selftest <ref-manual/ref-release-process:Testing and Quality Assurance>`.
+   through :ref:`bitbake-selftest <ref-manual/release-process:Testing and Quality Assurance>` and
+   :ref:`oe-selftest <ref-manual/release-process:Testing and Quality Assurance>`.
 
 -  *Automatic Upgrade Helper:* This target tests whether new versions of
    software are available and whether we can automatically upgrade to
@@ -310,7 +310,7 @@
 =============
 
 This section provides example tests for each of the tests listed in the
-:ref:`test-manual/test-manual-intro:How Tests Map to Areas of Code` section.
+:ref:`test-manual/intro:How Tests Map to Areas of Code` section.
 
 For oeqa tests, testcases for each area reside in the main test
 directory at ``meta/lib/oeqa/selftest/cases`` directory.
diff --git a/poky/documentation/test-manual/test-manual-test-process.rst b/poky/documentation/test-manual/test-process.rst
similarity index 95%
rename from poky/documentation/test-manual/test-manual-test-process.rst
rename to poky/documentation/test-manual/test-process.rst
index 82b9bb4..8a5e29d 100644
--- a/poky/documentation/test-manual/test-manual-test-process.rst
+++ b/poky/documentation/test-manual/test-process.rst
@@ -25,7 +25,7 @@
 
 Builds are triggered manually when the test branches are ready. The
 builds are monitored by the SWAT team. For additional information, see
-:yocto_wiki:`/wiki/Yocto_Build_Failure_Swat_Team`.
+:yocto_wiki:`/Yocto_Build_Failure_Swat_Team`.
 If successful, the changes would usually be merged to the ``master``
 branch. If not successful, someone would respond to the changes on the
 mailing list explaining that there was a failure in testing. The choice
@@ -35,9 +35,9 @@
 The Autobuilder does build the ``master`` branch once daily for several
 reasons, in particular, to ensure the current ``master`` branch does
 build, but also to keep ``yocto-testresults``
-(:yocto_git:`/cgit.cgi/yocto-testresults/`),
+(:yocto_git:`/yocto-testresults/`),
 buildhistory
-(:yocto_git:`/cgit.cgi/poky-buildhistory/`), and
+(:yocto_git:`/poky-buildhistory/`), and
 our sstate up to date. On the weekend, there is a master-next build
 instead to ensure the test results are updated for the less frequently
 run targets.
@@ -45,7 +45,7 @@
 Performance builds (buildperf-\* targets in the console) are triggered
 separately every six hours and automatically push their results to the
 buildstats repository at:
-:yocto_git:`/cgit.cgi/yocto-buildstats/`.
+:yocto_git:`/yocto-buildstats/`.
 
 The 'quick' targets have been selected to be the ones which catch the
 most failures or give the most valuable data. We run 'fast' ptests in
diff --git a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst b/poky/documentation/test-manual/understand-autobuilder.rst
similarity index 94%
rename from poky/documentation/test-manual/test-manual-understand-autobuilder.rst
rename to poky/documentation/test-manual/understand-autobuilder.rst
index 698a266..199cc97 100644
--- a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
+++ b/poky/documentation/test-manual/understand-autobuilder.rst
@@ -84,7 +84,7 @@
 
    This cleans out any previous build. Old builds are left around to
    allow easier debugging of failed builds. For additional information,
-   see :ref:`test-manual/test-manual-understand-autobuilder:clobberdir`.
+   see :ref:`test-manual/understand-autobuilder:clobberdir`.
 
 #. *Obtain yocto-autobuilder-helper*
 
@@ -108,7 +108,7 @@
    from the ``layerinfo.json`` file to help understand the
    configuration. It will also use a local cache of repositories to
    speed up the clone checkouts. For additional information, see
-   :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Clone Cache`.
+   :ref:`test-manual/understand-autobuilder:Autobuilder Clone Cache`.
 
    This step has two possible modes of operation. If the build is part
    of a parent build, its possible that all the repositories needed may
@@ -147,7 +147,7 @@
 deleting them. Files in this location are deleted by an ``rm`` command,
 which is run under ``ionice -c 3``. For example, the deletion only
 happens when there is idle IO capacity on the Worker. The Autobuilder
-Worker Janitor runs this deletion. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
+Worker Janitor runs this deletion. See :ref:`test-manual/understand-autobuilder:Autobuilder Worker Janitor`.
 
 Autobuilder Clone Cache
 -----------------------
@@ -157,13 +157,13 @@
 repositories pre-cloned on the Workers. Data is fetched from these
 during clones first, then "topped up" with later revisions from any
 upstream when necessary. The cache is maintained by the Autobuilder
-Worker Janitor. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
+Worker Janitor. See :ref:`test-manual/understand-autobuilder:Autobuilder Worker Janitor`.
 
 Autobuilder Worker Janitor
 --------------------------
 
 This is a process running on each Worker that performs two basic
-operations, including background file deletion at IO idle (see :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and
+operations, including background file deletion at IO idle (see :ref:`test-manual/understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and
 maintainenance of a cache of cloned repositories to improve the speed
 the system can checkout repositories.
 
@@ -195,7 +195,7 @@
 json results files. It has the ability to merge files together, display
 reports of the test results and compare different result files.
 
-For details, see :yocto_wiki:`/wiki/Resulttool`.
+For details, see :yocto_wiki:`/Resulttool`.
 
 run-config Target Execution
 ===========================
@@ -243,7 +243,7 @@
    generated to the remote server.
 
 #. Cleanup the build directory using
-   :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
+   :ref:`test-manual/understand-autobuilder:clobberdir` if the build was successful,
    else rename it to "build-renamed" for potential future debugging.
 
 Deploying Yocto Autobuilder
diff --git a/poky/documentation/toaster-manual/toaster-manual.rst b/poky/documentation/toaster-manual/index.rst
similarity index 65%
rename from poky/documentation/toaster-manual/toaster-manual.rst
rename to poky/documentation/toaster-manual/index.rst
index b003f1c..f13ba7b 100644
--- a/poky/documentation/toaster-manual/toaster-manual.rst
+++ b/poky/documentation/toaster-manual/index.rst
@@ -10,10 +10,10 @@
    :caption: Table of Contents
    :numbered:
 
-   toaster-manual-intro
-   toaster-manual-start
-   toaster-manual-setup-and-use
-   toaster-manual-reference
+   intro
+   start
+   setup-and-use
+   reference
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/toaster-manual/toaster-manual-intro.rst b/poky/documentation/toaster-manual/intro.rst
similarity index 97%
rename from poky/documentation/toaster-manual/toaster-manual-intro.rst
rename to poky/documentation/toaster-manual/intro.rst
index e34e7ba..c78b3f5 100644
--- a/poky/documentation/toaster-manual/toaster-manual-intro.rst
+++ b/poky/documentation/toaster-manual/intro.rst
@@ -25,7 +25,7 @@
    interface, you can:
 
    -  Browse layers listed in the various
-      :ref:`layer sources <toaster-manual/toaster-manual-reference:layer source>`
+      :ref:`layer sources <toaster-manual/reference:layer source>`
       that are available in your project (e.g. the OpenEmbedded Layer Index at
       http://layers.openembedded.org/layerindex/).
 
diff --git a/poky/documentation/toaster-manual/toaster-manual-reference.rst b/poky/documentation/toaster-manual/reference.rst
similarity index 95%
rename from poky/documentation/toaster-manual/toaster-manual-reference.rst
rename to poky/documentation/toaster-manual/reference.rst
index 2202d59..dfe5188 100644
--- a/poky/documentation/toaster-manual/toaster-manual-reference.rst
+++ b/poky/documentation/toaster-manual/reference.rst
@@ -25,8 +25,7 @@
 of custom layers. A good example of an existing layer index is the
 OpenEmbedded Layer Index. A public instance of this layer index exists
 at http://layers.openembedded.org. You can find the code for this
-layer index's web application at
-http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/.
+layer index's web application at :yocto_git:`/layerindex-web/`.
 
 When you tie a layer source into Toaster, it can query the layer source
 through a
@@ -66,9 +65,9 @@
 layers.
 
 For general information on layers, see the
-":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+":ref:`overview-manual/yp-intro:the yocto project layer model`"
 section in the Yocto Project Overview and Concepts Manual. For information on how
-to create layers, see the ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+to create layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section in the Yocto Project Development Tasks Manual.
 
 Configuring Toaster to Hook Into Your Layer Index
@@ -83,9 +82,8 @@
 
 In the previous section, the code for the OpenEmbedded Metadata Index
 (i.e. http://layers.openembedded.org) was referenced. You can use
-this code, which is at
-http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/, as a
-base to create your own layer index.
+this code, which is at :yocto_git:`/layerindex-web/`, as a base to create
+your own layer index.
 
 Use the Administration Interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -165,14 +163,13 @@
 -  *Yocto Project &DISTRO; "&DISTRO_NAME;" or OpenEmbedded "&DISTRO_NAME;":*
    This release causes your Toaster projects to build against the head
    of the &DISTRO_NAME_NO_CAP; branch at
-   https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=&DISTRO_NAME_NO_CAP; or
-   http://git.openembedded.org/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;.
+   :yocto_git:`/poky/log/?h=&DISTRO_NAME_NO_CAP;` or
+   :oe_git:`/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;`.
 
 -  *Yocto Project "Master" or OpenEmbedded "Master":* This release
    causes your Toaster Projects to build against the head of the master
    branch, which is where active development takes place, at
-   https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/ or
-   http://git.openembedded.org/openembedded-core/log/.
+   :yocto_git:`/poky/log/` or :oe_git:`/openembedded-core/log/`.
 
 -  *Local Yocto Project or Local OpenEmbedded:* This release causes your
    Toaster Projects to build against the head of the ``poky`` or
@@ -479,7 +476,7 @@
 
 Be sure to provide values for
 host, port, and ID. You can find the value for ID from the Builds
-Completed query. See the ":ref:`toaster-manual/toaster-manual-reference:checking status of builds completed`"
+Completed query. See the ":ref:`toaster-manual/reference:checking status of builds completed`"
 section for more information.
 
 The output is a JSON file that itemizes the specific build and includes
@@ -552,7 +549,7 @@
 
 You need to run the ``buildslist`` command first to identify existing
 builds in the database before using the
-:ref:`toaster-manual/toaster-manual-reference:\`\`builddelete\`\`` command. Here is an
+:ref:`toaster-manual/reference:\`\`builddelete\`\`` command. Here is an
 example that assumes default repository and build directory names:
 
 .. code-block:: shell
@@ -561,7 +558,7 @@
    $ python ../bitbake/lib/toaster/manage.py buildslist
 
 If your Toaster database had only one build, the above
-:ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\``
+:ref:`toaster-manual/reference:\`\`buildslist\`\``
 command would return something like the following::
 
    1: qemux86 poky core-image-minimal
@@ -582,7 +579,7 @@
 
 Prior to running the ``builddelete`` command, you need to get the ID
 associated with builds by using the
-:ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\`` command.
+:ref:`toaster-manual/reference:\`\`buildslist\`\`` command.
 
 ``perf``
 --------
diff --git a/poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst
similarity index 97%
rename from poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst
rename to poky/documentation/toaster-manual/setup-and-use.rst
index b73caac..2cb7884 100644
--- a/poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/poky/documentation/toaster-manual/setup-and-use.rst
@@ -10,7 +10,7 @@
 ======================================
 
 Once you have set up the Yocto Project and installed the Toaster system
-dependencies as described in the ":ref:`toaster-manual/toaster-manual-start:Preparing to Use
+dependencies as described in the ":ref:`toaster-manual/start:Preparing to Use
 Toaster`" chapter, you are ready to start
 Toaster.
 
@@ -30,7 +30,7 @@
 
 You can now run your builds from the command line, or with Toaster
 as explained in section
-":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`".
+":ref:`toaster-manual/setup-and-use:using the toaster web interface`".
 
 To access the Toaster web interface, open your favorite browser and
 enter the following::
@@ -200,7 +200,7 @@
 
    You must comply with all Apache, ``mod-wsgi``, and Mysql requirements.
 
--  Have all the build requirements as described in the ":ref:`toaster-manual/toaster-manual-start:Preparing to
+-  Have all the build requirements as described in the ":ref:`toaster-manual/start:Preparing to
    Use Toaster`" chapter.
 
 -  Have an Apache webserver.
@@ -314,7 +314,7 @@
     ``TEMPLATECONF`` value reflects the contents of
     ``poky/.templateconf``, and by default, should include the string
     "poky". For more information on the Toaster configuration file, see
-    the ":ref:`toaster-manual/toaster-manual-reference:Configuring Toaster`" section.
+    the ":ref:`toaster-manual/reference:Configuring Toaster`" section.
 
     This line also runs the ``checksettings`` command, which configures
     the location of the Toaster :term:`Build Directory`.
@@ -544,7 +544,7 @@
 
 This section only applies if you have set up Toaster for local
 development, as explained in the
-":ref:`toaster-manual/toaster-manual-setup-and-use:starting toaster for local development`"
+":ref:`toaster-manual/setup-and-use:starting toaster for local development`"
 section.
 
 When you create a project in Toaster, you will be asked to provide a
@@ -561,8 +561,8 @@
 this clone, your builds will always use the same Git revision.
 
 If you select any of the other release options, Toaster will fetch the
-tip of your selected release from the upstream `Yocto Project
-repository <https://git.yoctoproject.org>`__ every time you run a build.
+tip of your selected release from the upstream :yocto_git:`Yocto Project
+repository <>` every time you run a build.
 Fetching this tip effectively means that if your selected release is
 updated upstream, the Git revision you are using for your builds will
 change. If you are doing development locally, you might not want this
diff --git a/poky/documentation/toaster-manual/toaster-manual-start.rst b/poky/documentation/toaster-manual/start.rst
similarity index 95%
rename from poky/documentation/toaster-manual/toaster-manual-start.rst
rename to poky/documentation/toaster-manual/start.rst
index 8883374..c687a82 100644
--- a/poky/documentation/toaster-manual/toaster-manual-start.rst
+++ b/poky/documentation/toaster-manual/start.rst
@@ -14,7 +14,7 @@
 
 Before you can use Toaster, you need to first set up your build system
 to run the Yocto Project. To do this, follow the instructions in the
-":ref:`dev-manual/dev-manual-start:preparing the build host`" section of
+":ref:`dev-manual/start:preparing the build host`" section of
 the Yocto Project Development Tasks Manual. For Ubuntu/Debian, you might
 also need to do an additional install of pip3. ::
 
diff --git a/poky/documentation/transitioning-to-a-custom-environment.rst b/poky/documentation/transitioning-to-a-custom-environment.rst
index b87fec6..415f295 100644
--- a/poky/documentation/transitioning-to-a-custom-environment.rst
+++ b/poky/documentation/transitioning-to-a-custom-environment.rst
@@ -8,7 +8,7 @@
 
 .. note::
 
-   So you've finished the :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` and
+   So you've finished the :doc:`brief-yoctoprojectqs/index` and
    glanced over the document :doc:`what-i-wish-id-known`, the latter contains
    important information learned from other users. You're well prepared. But
    now, as you are starting your own project, it isn't exactly straightforward what
@@ -42,7 +42,7 @@
    You might want to start with the build specification that Poky provides
    (which is reference embedded distribution) and then add your newly chosen
    layers to that. Here is the information :ref:`about adding layers
-   <dev-manual/dev-manual-common-tasks:Understanding and Creating Layers>`.
+   <dev-manual/common-tasks:Understanding and Creating Layers>`.
 
 #. **Based on the layers you've chosen, make needed changes in your
    configuration**.
@@ -58,7 +58,7 @@
    releases. If you are using a Yocto Project release earlier than 2.4, use the
    ``yocto-layer create`` tool. The ``bitbake-layers`` tool also provides a number
    of other useful layer-related commands. See
-   :ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the
+   :ref:`dev-manual/common-tasks:creating a general layer using the
    \`\`bitbake-layers\`\` script` section.
 
 #. **Create your own layer for the BSP you're going to use**.
@@ -79,7 +79,7 @@
    process of refinement. Start by getting each step of the build process
    working beginning with fetching all the way through packaging. Next, run the
    software on your target and refine further as needed. See :ref:`Writing a New
-   Recipe <dev-manual/dev-manual-common-tasks:writing a new recipe>` in the
+   Recipe <dev-manual/common-tasks:writing a new recipe>` in the
    Yocto Project Development Tasks Manual for more information.
 
 #. **Now you're ready to create an image recipe**.
@@ -90,7 +90,7 @@
 
 #. **Build your image and refine it**.
    Add what's missing and fix anything that's broken using your knowledge of the
-   :ref:`workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk
+   :ref:`workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk
    workflow>` to identify where issues might be occurring.
 
 #. **Consider creating your own distribution**.
@@ -103,7 +103,7 @@
    needs to change for your distribution. If you find yourself adding a lot of
    configuration to your local.conf file aside from paths and other typical
    local settings, it's time to :ref:`consider creating your own distribution
-   <dev-manual/dev-manual-common-tasks:creating your own distribution>`.
+   <dev-manual/common-tasks:creating your own distribution>`.
 
    You can add product specifications that can customize the distribution if
    needed in other layers. You can also add other functionality specific to the
diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst
index afc1263..a051036 100644
--- a/poky/documentation/what-i-wish-id-known.rst
+++ b/poky/documentation/what-i-wish-id-known.rst
@@ -49,7 +49,7 @@
    their silicon. These layers have names such as "meta-intel" or "meta-ti". Try
    not to build layers from scratch. If you do have custom silicon, use one of
    these layers as a guide or template and familiarize yourself with the
-   :doc:`bsp-guide/bsp-guide`.
+   :doc:`bsp-guide/index`.
 
 #. **Do not put everything into one layer:**
    Use different layers to logically separate information in your build. As an
@@ -126,16 +126,16 @@
    You can build and run a specific task for a specific package (including
    devshell) or even a single recipe. When developers first start using the
    Yocto Project, the instructions found in the
-   :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` show how to create an image
+   :doc:`brief-yoctoprojectqs/index` show how to create an image
    and then run or flash that image.  However, you can actually build just a
    single recipe. Thus, if some dependency or recipe isn't working, you can just
    say "bitbake foo" where "foo" is the name for a specific recipe.  As you
    become more advanced using the Yocto Project, and if builds are failing, it
    can be useful to make sure the fetch itself works as desired. Here are some
-   valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development
+   valuable links: :ref:`dev-manual/common-tasks:Using a Development
    Shell` for information on how to build and run a specific task using
    devshell. Also, the :ref:`SDK manual shows how to build out a specific recipe
-   <sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`.
+   <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`.
 
 #. **An ambiguous definition: Package vs Recipe:**
    A recipe contains instructions the build system uses to create
@@ -190,28 +190,28 @@
      contains procedural information grouped to help you get set up, work with
      layers, customize images, write new recipes, work with libraries, and use
      QEMU. The information is task-based and spans the breadth of the Yocto
-     Project. See the :doc:`../dev-manual/dev-manual`.
+     Project. See the :doc:`/dev-manual/index`.
 
    * **Look Through the Yocto Project Application Development and the Extensible
      Software Development Kit (eSDK) manual**: This manual describes how to use
      both the standard SDK and the extensible SDK, which are used primarily for
-     application development. The :doc:`../sdk-manual/sdk-extensible` also provides
+     application development. The :doc:`/sdk-manual/extensible` also provides
      example workflows that use devtool. See the section
-     :ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`
+     :ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`
      for more information.
 
    * **Learn About Kernel Development**: If you want to see how to work with the
-     kernel and understand Yocto Linux kernels, see the :doc:`../kernel-dev/kernel-dev`.
+     kernel and understand Yocto Linux kernels, see the :doc:`/kernel-dev/index`.
      This manual provides information on how to patch the kernel, modify kernel
      recipes, and configure the kernel.
 
    * **Learn About Board Support Packages (BSPs)**: If you want to learn about
-     BSPs, see the :doc:`../bsp-guide/bsp-guide`. This manual also provides an
-     example BSP creation workflow. See the :doc:`../bsp-guide/bsp` section.
+     BSPs, see the :doc:`/bsp-guide/index`. This manual also provides an
+     example BSP creation workflow. See the :doc:`/bsp-guide/bsp` section.
 
    * **Learn About Toaster**: Toaster is a web interface to the Yocto Project's
      OpenEmbedded build system. If you are interested in using this type of
-     interface to create images, see the :doc:`../toaster-manual/toaster-manual`.
+     interface to create images, see the :doc:`/toaster-manual/index`.
 
    * **Have Available the Yocto Project Reference Manual**: Unlike the rest of
      the Yocto Project manual set, this manual is comprised of material suited
@@ -219,7 +219,7 @@
      look at how the pieces of the Yocto Project development environment work
      together, information on various technical details, guidance on migrating
      to a newer Yocto Project release, reference material on the directory
-     structure, classes, and tasks. The :doc:`../ref-manual/ref-manual` also
+     structure, classes, and tasks. The :doc:`/ref-manual/index` also
      contains a fairly comprehensive glossary of variables used within the Yocto
      Project.