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