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,