meta-openembedded and poky: subtree updates

Squash of the following due to dependencies among them
and OpenBMC changes:

meta-openembedded: subtree update:d0748372d2..9201611135
meta-openembedded: subtree update:9201611135..17fd382f34
poky: subtree update:9052e5b32a..2e11d97b6c
poky: subtree update:2e11d97b6c..a8544811d7

The change log was too large for the jenkins plugin
to handle therefore it has been removed. Here is
the first and last commit of each subtree:

meta-openembedded:d0748372d2
      cppzmq: bump to version 4.6.0
meta-openembedded:17fd382f34
      mpv: Remove X11 dependency
poky:9052e5b32a
      package_ipk: Remove pointless comment to trigger rebuild
poky:a8544811d7
      pbzip2: Fix license warning

Change-Id: If0fc6c37629642ee207a4ca2f7aa501a2c673cd6
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>

30 files changed, 1276 insertions, 592 deletions

diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile
index 525a7309a..15644bf92 100644
--- a/poky/documentation/Makefile
+++ b/poky/documentation/Makefile
@@ -76,6 +76,11 @@
 # example publishes the 1.2 version of the PDF and HTML YP Development Tasks Manual
 # for the 'denzil' branch.
 #
+# IN MEMORIAM: This comment is to remember Scott Rifenbark (scottrif), whom we lost
+# in January, 2020. Scott was the primary technical writer for the Yocto Project for
+# over 9 years. In that time, he contributed many thousands of patches, built this
+# documentation tree, and enabled tens of thousands of developers to succeed with
+# embedded Linux. He ran this Makefile many thousands of times. Godspeed, Dude.
 
 ifeq ($(DOC),brief-yoctoprojectqs)
 XSLTOPTS = --stringparam html.stylesheet brief-yoctoprojectqs-style.css \
@@ -414,8 +419,8 @@ publish:
             echo " "; \
             echo "******** Publishing "$(DOC)".html"; \
             echo " "; \
-            scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
-            cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
+            scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
+            cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
 	else \
           echo " "; \
           echo $(DOC)".html missing.  Generate the file first then try again."; \
diff --git a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml
index 1daeb2547..3c83afd46 100644
--- a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml
+++ b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml
@@ -55,10 +55,18 @@
                         information.
                         </para></listitem>
                     <listitem><para>
-                        You cannot use a build host that is using the
-                        <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink>
-                        (WSL).
-                        The Yocto Project is not compatible with WSL.
+                        You may use Windows Subsystem For Linux v2 to set up a build
+                        host using Windows 10.
+                        <note>
+                          The Yocto Project is not compatible with WSLv1, it is
+                          compatible but not officially supported nor validated
+                          with WSLv2, if you still decide to use WSL please upgrade
+                          to WSLv2.
+                        </note>
+                        See the
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>"
+                        section in the Yocto Project Development Tasks Manual for more
+                        information.
                         </para></listitem>
                 </itemizedlist>
             </note>
@@ -99,17 +107,20 @@
                             Git 1.8.3.1 or greater
                             </para></listitem>
                         <listitem><para>
-                            tar 1.27 or greater
+                            tar 1.28 or greater
                             </para></listitem>
                         <listitem><para>
-                            Python 3.4.0 or greater.
-                            </para></listitem>
+                            Python 3.5.0 or greater.
+                        </para></listitem>
+                        <listitem><para>
+                            gcc 5.0 or greater.
+                        </para></listitem>
                     </itemizedlist>
                     If your build host does not meet any of these three listed
                     version requirements, you can take steps to prepare the
                     system so that you can still use the Yocto Project.
                     See the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>"
                     section in the Yocto Project Reference Manual for information.
                     </para></listitem>
             </itemizedlist>
@@ -266,7 +277,7 @@
          meta-toolchain
          meta-ide-support
 
-     You can also run generated qemu images with a command like 'runqemu qemux86'
+     You can also run generated qemu images with a command like 'runqemu qemux86-64'
                     </literallayout>
                     Among other things, the script creates the
                     <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
@@ -332,7 +343,7 @@
                     QEMU, which is a Quick EMUlator that ships with
                     the Yocto Project:
                     <literallayout class='monospaced'>
-     $ runqemu qemux86
+     $ runqemu qemux86-64
                     </literallayout>
                     If you want to learn more about running QEMU, see the
                     "<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>"
diff --git a/poky/documentation/bsp-guide/bsp-guide.xml b/poky/documentation/bsp-guide/bsp-guide.xml
index dd0c76add..a189606ce 100644..100755
--- a/poky/documentation/bsp-guide/bsp-guide.xml
+++ b/poky/documentation/bsp-guide/bsp-guide.xml
@@ -22,33 +22,27 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
         <revhistory>
             <revision>
                 <revnumber>0.9</revnumber>
-                <date>24 November 2010</date>
-                <revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
+                <date>November 2010</date>
+                <revremark>The initial document released with the Yocto Project 0.9 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
+                <date>April 2011</date>
                 <revremark>Released with the Yocto Project 1.0 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.0.1</revnumber>
-                <date>23 May 2011</date>
-                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.1</revnumber>
-                <date>6 October 2011</date>
+                <date>October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
             <revision>
@@ -72,11 +66,6 @@
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.6</revnumber>
                 <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
@@ -133,9 +122,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -157,7 +151,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -174,18 +168,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/bsp-guide/bsp.xml b/poky/documentation/bsp-guide/bsp.xml
index 58f5733f7..96c0455f6 100644
--- a/poky/documentation/bsp-guide/bsp.xml
+++ b/poky/documentation/bsp-guide/bsp.xml
@@ -19,7 +19,7 @@
 </para>
 
 <para>
-    This guide presents information about BSP Layers, defines a structure for components
+    This guide presents information about BSP layers, defines a structure for components
     so that BSPs follow a commonly understood layout, discusses how to customize
     a recipe for a BSP, addresses BSP licensing, and provides information that
     shows you how to create a
@@ -34,7 +34,7 @@
     <para>
         A BSP consists of a file structure inside a base directory.
         Collectively, you can think of the base directory, its file structure,
-        and the contents as a BSP Layer.
+        and the contents as a <firstterm>BSP layer</firstterm>.
         Although not a strict requirement, BSP layers in the Yocto Project
         use the following well-established naming convention:
         <literallayout class='monospaced'>
@@ -69,9 +69,9 @@
         Each repository is a BSP layer supported by the Yocto Project
         (e.g. <filename>meta-raspberrypi</filename> and
         <filename>meta-intel</filename>).
-        Each of these layers is a repository unto itself and clicking on a
-        layer reveals information that includes two links from which you can choose
-        to set up a clone of the layer's repository on your local host system.
+        Each of these layers is a repository unto itself and clicking on
+        the layer name displays two URLs from which you can
+        clone the layer's repository to your local system.
         Here is an example that clones the Raspberry Pi BSP layer:
         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/meta-raspberrypi
@@ -83,12 +83,13 @@
         <filename>meta-yocto-bsp</filename> layer is part of the
         shipped <filename>poky</filename> repository.
         The <filename>meta-yocto-bsp</filename> layer maintains several
-        BSPs such as the Beaglebone, EdgeRouter, and generic versions of
+        "reference" BSPs including the ARM-based Beaglebone, MIPS-based
+        EdgeRouter, and generic versions of
         both 32-bit and 64-bit IA machines.
     </para>
 
     <para>
-        For information on the BSP development workflow, see the
+        For information on typical BSP development workflow, see the
         "<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>"
         section.
         For more information on how to set up a local copy of source files
@@ -98,12 +99,12 @@
     </para>
 
     <para>
-        The layer's base directory
+        The BSP layer's base directory
         (<filename>meta-<replaceable>bsp_root_name</replaceable></filename>)
-        is the root directory of the BSP Layer.
+        is the root directory of that Layer.
         This directory is what you add to the
         <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
-        variable in the <filename>conf/bblayers.conf</filename> file found in the
+        variable in the <filename>conf/bblayers.conf</filename> file found in your
         <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
         which is established after you run the OpenEmbedded build environment
         setup script (i.e.
@@ -153,6 +154,20 @@
         layer.
         The <filename>meta-openembedded</filename> layer contains
         many <filename>meta-*</filename> layers.
+        In cases like this, you need to include the names of the actual
+        layers you want to work with, such as:
+        <literallayout class='monospaced'>
+     BBLAYERS ?= " \
+       /usr/local/src/yocto/meta \
+       /usr/local/src/yocto/meta-poky \
+       /usr/local/src/yocto/meta-yocto-bsp \
+       /usr/local/src/yocto/meta-mylayer \
+       .../meta-openembedded/meta-oe \
+       .../meta-openembedded/meta-perl \
+       .../meta-openembedded/meta-networking \
+       "
+        </literallayout>
+       and so on.
     </para>
 
     <para>
@@ -351,25 +366,24 @@
         layer combined with a build system and other tools.
         Realize that it is important to maintain the distinction
         that the BSP layer, a build system, and tools are
-        separate components that could to be combined in
+        separate components that could be combined in
         certain end products.
     </para>
 
     <para>
-        Before looking at the common form for the file structure
-        inside a BSP Layer, you should be aware that some
+        Before looking at the recommended form for the directory structure
+        inside a BSP layer, you should be aware that some
         requirements do exist in order for a BSP layer to
-        be considered compliant with the Yocto Project.
+        be considered <firstterm>compliant</firstterm> with the Yocto Project.
         For that list of requirements, see the
         "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>"
         section.
     </para>
 
     <para>
-        Below is the common form for the file structure
-        inside a BSP Layer.
+        Below is the typical directory structure for a BSP layer.
         While this basic form represents the standard,
-        realize that the actual file structures for specific
+        realize that the actual layout for individual
         BSPs could differ.
         <literallayout class='monospaced'>
      meta-<replaceable>bsp_root_name</replaceable>/
@@ -567,7 +581,7 @@
             for the BSP.
             The type or types of files here can vary depending
             on the licensing requirements.
-            For example, in the Raspberry Pi BSP all licensing
+            For example, in the Raspberry Pi BSP, all licensing
             requirements are handled with the
             <filename>COPYING.MIT</filename> file.
         </para>
@@ -802,7 +816,7 @@
             <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
             For example, many <filename>tune-*</filename> files
             (e.g. <filename>tune-arm1136jf-s.inc</filename>,
-            <filename>tun-1586-nlp.inc</filename>, and so forth)
+            <filename>tune-1586-nlp.inc</filename>, and so forth)
             reside in the
             <filename>poky/meta/conf/machine/include</filename>
             directory.
@@ -834,7 +848,7 @@
             This optional directory contains miscellaneous recipe
             files for the BSP.
             Most notably would be the formfactor files.
-            For example, in the Raspberry Pi BSP there is the
+            For example, in the Raspberry Pi BSP, there is the
             <filename>formfactor_0.0.bbappend</filename> file,
             which is an append file used to augment the recipe
             that starts the build.
@@ -901,7 +915,7 @@
             The <filename>*.bb</filename> files would be a
             developer-supplied kernel recipe.
             This area of the BSP hierarchy can contain both these
-            types of files, although in practice, it is likely that
+            types of files although, in practice, it is likely that
             you would have one or the other.
         </para>
 
@@ -976,7 +990,7 @@
     <title>Developing a Board Support Package (BSP)</title>
 
     <para>
-        This section contains the high-level procedure you can
+        This section describes the high-level procedure you can
         follow to create a BSP.
         Although not required for BSP creation, the
         <filename>meta-intel</filename> repository, which
@@ -1075,10 +1089,6 @@
                                     (<filename>beaglebone-yocto</filename>)
                                     </para></listitem>
                                 <listitem><para>
-                                    Freescale MPC8315E-RDB
-                                    (<filename>mpc8315e-rdb</filename>)
-                                    </para></listitem>
-                                <listitem><para>
                                     Ubiquiti Networks EdgeRouter Lite
                                    (<filename>edgerouter</filename>)
                                    </para></listitem>
@@ -1302,7 +1312,7 @@
                     (<filename>openembedded-core</filename>)
                     or the Source Directory (<filename>poky</filename>).
                     In other words, make sure you place related
-                    files in appropriately related
+                    files in appropriately-related
                     <filename>recipes-*</filename> subdirectories
                     specific to the recipe's function, or within
                     a subdirectory containing a set of closely-related
@@ -1319,7 +1329,7 @@
                     directory.
                     This license covers the BSP Metadata as a whole.
                     You must specify which license to use since no
-                    default license exists when one not specified.
+                    default license exists when one is not specified.
                     See the
                     <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
                     file for the Raspberry Pi BSP in the
@@ -1342,12 +1352,10 @@
                     file should contain the following:
                     <itemizedlist>
                         <listitem><para>
-                            A brief description about the hardware the BSP
-                            targets.
+                            A brief description of the target hardware.
                             </para></listitem>
                         <listitem><para>
-                            A list of all the dependencies
-                            on which a BSP layer depends.
+                            A list of all the dependencies of the BSP.
                             These dependencies are typically a list
                             of required layers needed to build the
                             BSP.
@@ -1610,7 +1618,7 @@
     <title>BSP Licensing Considerations</title>
 
     <para>
-        In some cases, a BSP contains separately licensed
+        In some cases, a BSP contains separately-licensed
         Intellectual Property (IP) for a component or components.
         For these cases, you are required to accept the terms
         of a commercial or other type of license that requires
@@ -1623,7 +1631,7 @@
     </para>
 
     <para>
-        You could find that some separately licensed components
+        You could find that some separately-licensed components
         that are essential for normal operation of the system might
         not have an unencumbered (or free) substitute.
         Without these essential components, the system would be
@@ -1631,7 +1639,7 @@
         Then again, you might find that other licensed components
         that are simply 'good-to-have' or purely elective do have
         an unencumbered, free replacement component that you can
-        use rather than agreeing to the separately licensed
+        use rather than agreeing to the separately-licensed
         component.
         Even for components essential to the system, you might
         find an unencumbered component that is not identical but
@@ -1744,7 +1752,7 @@
     <para>
         The <filename>bitbake-layers create-layer</filename> script
         automates creating a BSP layer.
-        What makes a layer a "BSP layer", is the presence of a machine
+        What makes a layer a "BSP layer" is the presence of at least one machine
         configuration file.
         Additionally, a BSP layer usually has a kernel recipe
         or an append file that leverages off an existing kernel recipe.
@@ -1868,11 +1876,14 @@
         </para>
 
         <para>
-            Machine configuration files exist in the
+            One or more machine configuration files exist in the
             <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename>
             directory of the layer:
             <literallayout class='monospaced'>
-     <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine</replaceable><filename>.conf</filename>
+     <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine1</replaceable><filename>.conf</filename>
+     <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine2</replaceable><filename>.conf</filename>
+     <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine3</replaceable><filename>.conf</filename>
+     ... more ...
             </literallayout>
             For example, the machine configuration file for the
             <ulink url='http://beagleboard.org/bone'>BeagleBone and BeagleBone Black development boards</ulink>
@@ -1923,8 +1934,8 @@
      IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
             </literallayout>
             The variables used to configure the machine define
-            machine-specific properties.
-            For example, machine-dependent packages, machine
+            machine-specific properties;
+            for example, machine-dependent packages, machine
             tunings, the type of kernel to build, and
             U-Boot configurations.
         </para>
@@ -1935,7 +1946,7 @@
             machine configuration file for the BeagleBone
             development boards.
             Realize that much more can be defined as part of
-            a machines configuration file.
+            a machine's configuration file.
             In general, you can learn about related variables
             that this example does not have by locating the
             variables in the
@@ -2182,7 +2193,6 @@
      KBRANCH_genericx86-64  = "v5.0/standard/base"
      KBRANCH_edgerouter = "v5.0/standard/edgerouter"
      KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone"
-     KBRANCH_mpc8315e-rdb = "v5.0/standard/fsl-mpc8315e-rdb"
 
      KMACHINE_genericx86 ?= "common-pc"
      KMACHINE_genericx86-64 ?= "common-pc-64"
@@ -2192,19 +2202,16 @@
      SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
      SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
      SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-     SRCREV_machine_mpc8315e-rdb ?= "8b62af7f252af10588276802c4c6d7c502e875be"
 
      COMPATIBLE_MACHINE_genericx86 = "genericx86"
      COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
      COMPATIBLE_MACHINE_edgerouter = "edgerouter"
      COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
-     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
      LINUX_VERSION_genericx86 = "5.0.3"
      LINUX_VERSION_genericx86-64 = "5.0.3"
      LINUX_VERSION_edgerouter = "5.0.3"
      LINUX_VERSION_beaglebone-yocto = "5.0.3"
-     LINUX_VERSION_mpc8315e-rdb = "5.0.3"
             </literallayout>
             This particular append file works for all the
             machines that are part of the
diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
index 00741ee45..e9ce182a5 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -184,6 +184,10 @@
                                 variable.
                                 </para></listitem>
                             <listitem><para>
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></ulink>:
+                                Lists all layers on which this layer depends (if any).
+                                </para></listitem>
+                            <listitem><para>
                                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERSERIES_COMPAT'><filename>LAYERSERIES_COMPAT</filename></ulink>:
                                 Lists the
                                 <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Yocto Project</ulink>
@@ -315,12 +319,26 @@
      DEPENDS_append_one = " foo"
      DEPENDS_prepend_one = "foo "
                                 </literallayout>
-                                As an actual example, here's a line from the recipe
-                                for gnutls, which adds dependencies on
-                                "argp-standalone" when building with the musl C
-                                library:
+                                As an actual example, here's a snippet from the
+                                generic kernel include file
+                                <filename>linux-yocto.inc</filename>,
+                                wherein the kernel compile and link options are
+                                adjusted in the case of a subset of the supported
+                                architectures:
                                 <literallayout class='monospaced'>
-     DEPENDS_append_libc-musl = " argp-standalone"
+     DEPENDS_append_aarch64 = " libgcc"
+     KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+     KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+
+     DEPENDS_append_nios2 = " libgcc"
+     KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+     KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+
+     DEPENDS_append_arc = " libgcc"
+     KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}"
+     KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}"
+
+     KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
                                 </literallayout>
                                 <note>
                                     Avoiding "+=" and "=+" and using
@@ -580,11 +598,19 @@
                             <filename>bitbake -e</filename>).
                             </para></listitem>
                         <listitem><para>
+                            <filename>common.test_world</filename>:
+                            Verifies that <filename>bitbake world</filename> works.
+                            </para></listitem>
+                        <listitem><para>
                             <filename>common.test_signatures</filename>:
                             Tests to be sure that BSP and DISTRO layers do not
                             come with recipes that change signatures.
                             </para></listitem>
                         <listitem><para>
+                            <filename>common.test_layerseries_compat</filename>:
+                            Verifies layer compatibility is set properly.
+                            </para></listitem>
+                        <listitem><para>
                             <filename>bsp.test_bsp_defines_machines</filename>:
                             Tests if a BSP layer has machine configurations.
                             </para></listitem>
@@ -594,11 +620,22 @@
                             machine when the layer is added.
                             </para></listitem>
                         <listitem><para>
+                            <filename>bsp.test_machine_world</filename>:
+                            Verifies that <filename>bitbake world</filename>
+                            works regardless of which machine is selected.
+                            </para></listitem>
+                        <listitem><para>
+                            <filename>bsp.test_machine_signatures</filename>:
+                            Verifies that building for a particular machine
+                            affects only the signature of tasks specific to that
+                            machine.
+                            </para></listitem>
+                        <listitem><para>
                             <filename>distro.test_distro_defines_distros</filename>:
                             Tests if a DISTRO layer has distro configurations.
                             </para></listitem>
                         <listitem><para>
-                            <filename>distro.test_distro_no_set_distro</filename>:
+                            <filename>distro.test_distro_no_set_distros</filename>:
                             Tests to ensure a DISTRO layer does not set the
                             distribution when the layer is added.
                             </para></listitem>
@@ -1397,7 +1434,7 @@
                 package specified in the <filename>PACKAGES</filename>
                 statement.
                 <note>
-                    The <filename>inherit packages</filename> should be
+                    The <filename>inherit packagegroup</filename> line should be
                     located near the top of the recipe, certainly before
                     the <filename>PACKAGES</filename> statement.
                 </note>
@@ -1417,28 +1454,32 @@
 
             <para>
                 Here is a short, fabricated example showing the same basic
-                pieces:
+                pieces for a hypothetical packagegroup defined in
+                <filename>packagegroup-custom.bb</filename>, where the
+                variable <filename>PN</filename> is the standard way to
+                abbreviate the reference to the full packagegroup name
+                <filename>packagegroup-custom</filename>:
                 <literallayout class='monospaced'>
      DESCRIPTION = "My Custom Package Groups"
 
      inherit packagegroup
 
      PACKAGES = "\
-         packagegroup-custom-apps \
-         packagegroup-custom-tools \
+         ${PN}-apps \
+         ${PN}-tools \
          "
 
-     RDEPENDS_packagegroup-custom-apps = "\
+     RDEPENDS_${PN}-apps = "\
          dropbear \
          portmap \
          psplash"
 
-     RDEPENDS_packagegroup-custom-tools = "\
+     RDEPENDS_${PN}-tools = "\
          oprofile \
          oprofileui-server \
          lttng-tools"
 
-     RRECOMMENDS_packagegroup-custom-tools = "\
+     RRECOMMENDS_${PN}-tools = "\
          kernel-module-oprofile"
                 </literallayout>
             </para>
@@ -1900,9 +1941,9 @@
             <para>
                 The <filename>SRC_URI</filename> variable in your recipe must
                 define each unique location for your source files.
-                It is good practice to not hard-code pathnames in an URL used
+                It is good practice to not hard-code version numbers in a URL used
                 in <filename>SRC_URI</filename>.
-                Rather than hard-code these paths, use
+                Rather than hard-code these values, use
                 <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink><filename>}</filename>,
                 which causes the fetch process to use the version specified in
                 the recipe filename.
@@ -1913,13 +1954,13 @@
 
             <para>
                 Here is a simple example from the
-                <filename>meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb</filename>
+                <filename>meta/recipes-devtools/strace/strace_5.5.bb</filename>
                 recipe where the source comes from a single tarball.
                 Notice the use of the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
                 variable:
                 <literallayout class='monospaced'>
-     SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2"
+     SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
                 </literallayout>
             </para>
 
@@ -1978,16 +2019,17 @@
                 For these cases, you provide a name for each URL as part of
                 the <filename>SRC_URI</filename> and then reference that name
                 in the subsequent checksum statements.
-                Here is an example:
+                Here is an example combining lines from the files
+                <filename>git.inc</filename> and
+                <filename>git_2.24.1.bb</filename>:
                 <literallayout class='monospaced'>
-     SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
-                ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch"
+     SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
+                ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
 
-     SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8"
-     SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d"
-
-     SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92"
-     SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430"
+     SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b"
+     SRC_URI[tarball.sha256sum] = "ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02"
+     SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d"
+     SRC_URI[manpages.sha256sum] = "9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230"
                 </literallayout>
             </para>
 
@@ -3242,8 +3284,6 @@
                 The script defined in the post-installation function is
                 called when the root filesystem is created.
                 If the script succeeds, the package is marked as installed.
-                If the script fails, the package is marked as unpacked and
-                the script is executed when the image boots again.
                 <note>
                     Any RPM post-installation script that runs on the target
                     should return a 0 exit code.
@@ -3262,7 +3302,7 @@
                 mark post installs to defer to the target.
                 You can use <filename>pkg_postinst_ontarget()</filename> or
                 call
-                <filename>postinst-intercepts defer_to_first_boot</filename>
+                <filename>postinst_intercept delay_to_first_boot</filename>
                 from <filename>pkg_postinst()</filename>.
                 Any failure of a <filename>pkg_postinst()</filename> script
                 (including exit 1) triggers an error during the
@@ -7609,7 +7649,6 @@
                 available Wic images as follows:
                 <literallayout class='monospaced'>
      $ wic list images
-       mpc8315e-rdb                  		Create SD card image for MPC8315E-RDB
        genericx86                    		Create an EFI disk image for genericx86*
        beaglebone-yocto              		Create SD card image for Beaglebone
        edgerouter                    		Create SD card image for Edgerouter
@@ -7797,7 +7836,6 @@
                 files:
                 <literallayout class='monospaced'>
      $ wic list images
-       mpc8315e-rdb                  		Create SD card image for MPC8315E-RDB
        genericx86                    		Create an EFI disk image for genericx86*
        beaglebone-yocto              		Create SD card image for Beaglebone
        edgerouter                    		Create SD card image for Edgerouter
@@ -10550,7 +10588,7 @@
                     <filename>devtool</filename> and the NPM fetcher to
                     create the recipe:
                     <literallayout class='monospaced'>
-     $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2"
+     $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2"
                     </literallayout>
                     The <filename>devtool add</filename> command runs
                     <filename>recipetool create</filename> and uses the
@@ -10575,25 +10613,13 @@
                 </para>
 
                 <para>
-                    <filename>recipetool</filename> creates "shrinkwrap" and
-                    "lockdown" files for your recipe.
+                    <filename>recipetool</filename> creates a "shrinkwrap" file
+                    for your recipe.
                     Shrinkwrap files capture the version of all dependent
                     modules.
                     Many packages do not provide shrinkwrap files.
                     <filename>recipetool</filename> create a shrinkwrap
                     file as it runs.
-                    You can replace the shrinkwrap file with your own file
-                    by setting the <filename>NPM_SHRINKWRAP</filename>
-                    variable.
-                </para>
-
-                <para>
-                    Lockdown files contain the checksum for each module
-                    to determine if your users download the same files when
-                    building with a recipe.
-                    Lockdown files ensure that dependencies have not been
-                    changed and that your NPM registry is still providing
-                    the same file.
                     <note>
                         A package is created for each sub-module.
                         This policy is the only practical way to have the
@@ -10608,23 +10634,26 @@
                     <literallayout class='monospaced'>
      $ devtool edit-recipe cute-files
      SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
-     LICENSE = "BSD-3-Clause &amp; Unknown &amp; MIT &amp; ISC"
+     LICENSE = "MIT &amp; ISC &amp; Unknown"
      LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
-                         file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \
-                         file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \
+                         file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \
+                         file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \
                          ...
 
-     SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}"
-     NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
-     NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"
+     SRC_URI = " \
+         npm://registry.npmjs.org/;package=cute-files;version=${PV} \
+         npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+     "
+
+     S = "${WORKDIR}/npm"
+
      inherit npm
-     # Must be set after inherit npm since that itself sets S
-     S = "${WORKDIR}/npmpkg"
 
-     LICENSE_${PN}-content-disposition = "MIT"
-     ...
-     LICENSE_${PN}-express = "MIT"
      LICENSE_${PN} = "MIT"
+     LICENSE_${PN}-accepts = "MIT"
+     LICENSE_${PN}-array-flatten = "MIT"
+     ...
+     LICENSE_${PN}-vary = "MIT"
                     </literallayout>
                     Three key points exist in the previous example:
                     <itemizedlist>
@@ -10717,11 +10746,10 @@
                     However, the <filename>SRC_URI</filename> looks like the
                     following:
                     <literallayout class='monospaced'>
-     SRC_URI = "git://github.com/martinaglv/cute-files.git;protocol=https \
-               npm://registry.npmjs.org;name=commander;version=2.9.0;subdir=node_modules/commander \
-               npm://registry.npmjs.org;name=express;version=4.14.0;subdir=node_modules/express \
-               npm://registry.npmjs.org;name=content-disposition;version=0.3.0;subdir=node_modules/content-disposition \
-               "
+     SRC_URI = " \
+         git://github.com/martinaglv/cute-files.git;protocol=https \
+         npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+         "
                     </literallayout>
                     In this example, the main module is taken from the Git
                     repository and dependents are taken from the NPM registry.
@@ -10822,7 +10850,7 @@
                 Use the following BitBake command form to fetch all the
                 necessary sources without starting the build:
                 <literallayout class='monospaced'>
-     $ bitbake -c <replaceable>target</replaceable> runall="fetch"
+     $ bitbake <replaceable>target</replaceable> --runall=fetch
                 </literallayout>
                 This variation of the BitBake command guarantees that you
                 have all the sources for that BitBake target should you
@@ -10845,15 +10873,6 @@
         </para>
 
         <para>
-            By default, the Yocto Project uses SysVinit as the initialization
-            manager.
-            However, support also exists for systemd,
-            which is a full replacement for init with
-            parallel starting of services, reduced shell overhead and other
-            features that are used by many distributions.
-        </para>
-
-        <para>
             Within the system, SysVinit treats system components as services.
             These services are maintained as shell scripts stored in the
             <filename>/etc/init.d/</filename> directory.
@@ -11164,18 +11183,18 @@
 
             <para>
                 To create the read-only root filesystem, simply add the
-                "read-only-rootfs" feature to your image.
-                Using either of the following statements in your
-                image recipe or from within the
-                <filename>local.conf</filename> file found in the
-                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
-                causes the build system to create a read-only root filesystem:
+                "read-only-rootfs" feature to your image, normally in one of two ways.
+                The first way is to add the "read-only-rootfs" image feature
+                in the image's recipe file via the
+                <filename>IMAGE_FEATURES</filename> variable:
                 <literallayout class='monospaced'>
-     IMAGE_FEATURES = "read-only-rootfs"
+     IMAGE_FEATURES += "read-only-rootfs"
                 </literallayout>
-                or
+                As an alternative, you can add the same feature from within your
+                build directory's <filename>local.conf</filename> file with the
+                associated <filename>EXTRA_IMAGE_FEATURES</filename> variable, as in:
                 <literallayout class='monospaced'>
-     EXTRA_IMAGE_FEATURES += "read-only-rootfs"
+     EXTRA_IMAGE_FEATURES = "read-only-rootfs"
                 </literallayout>
             </para>
 
@@ -12038,15 +12057,15 @@
                     In order to run tests on hardware, you need to set
                     <filename>TEST_TARGET</filename> to an appropriate value.
                     For QEMU, you do not have to change anything, the default
-                    value is "QemuTarget".
+                    value is "qemu".
                     For running tests on hardware, the following options exist:
                     <itemizedlist>
-                        <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
-                            Choose "SimpleRemoteTarget" if you are going to
+                        <listitem><para><emphasis>"simpleremote":</emphasis>
+                            Choose "simpleremote" if you are going to
                             run tests on a target system that is already
                             running the image to be tested and is available
                             on the network.
-                            You can use "SimpleRemoteTarget" in conjunction
+                            You can use "simpleremote" in conjunction
                             with either real hardware or an image running
                             within a separately started QEMU or any
                             other virtual machine manager.
@@ -12221,7 +12240,7 @@
                 <title>Power Control</title>
 
                 <para>
-                    For most hardware targets other than SimpleRemoteTarget,
+                    For most hardware targets other than "simpleremote",
                     you can control power:
                     <itemizedlist>
                         <listitem><para>
@@ -12618,7 +12637,7 @@
                                 <listitem><para><emphasis><filename>target</filename>:</emphasis>
                                     The target controller object used to deploy
                                     and start an image on a particular target
-                                    (e.g. QemuTarget, SimpleRemote, and
+                                    (e.g. Qemu, SimpleRemote, and
                                     SystemdbootTarget).
                                     Tests usually use the following:
                                     <itemizedlist>
diff --git a/poky/documentation/dev-manual/dev-manual-qemu.xml b/poky/documentation/dev-manual/dev-manual-qemu.xml
index f5a0d64af..5ccc0dfe8 100644
--- a/poky/documentation/dev-manual/dev-manual-qemu.xml
+++ b/poky/documentation/dev-manual/dev-manual-qemu.xml
@@ -151,13 +151,13 @@
                     <itemizedlist>
                         <listitem><para>
                             This example starts QEMU with
-                            <replaceable>MACHINE</replaceable> set to "qemux86".
+                            <replaceable>MACHINE</replaceable> set to "qemux86-64".
                             Assuming a standard
                             <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
                             <filename>runqemu</filename> automatically finds the
-                            <filename>bzImage-qemux86.bin</filename> image file and
+                            <filename>bzImage-qemux86-64.bin</filename> image file and
                             the
-                            <filename>core-image-minimal-qemux86-20140707074611.rootfs.ext3</filename>
+                            <filename>core-image-minimal-qemux86-64-20200218002850.rootfs.ext4</filename>
                             (assuming the current build created a
                             <filename>core-image-minimal</filename> image).
                             <note>
@@ -166,7 +166,7 @@
                             timestamp.
                             </note>
                             <literallayout class='monospaced'>
-     $ runqemu qemux86
+     $ runqemu qemux86-64
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -175,7 +175,7 @@
                             This command, however, specifically provides the image
                             and root filesystem type.
                             <literallayout class='monospaced'>
-     $ runqemu qemux86 core-image-minimal ext3
+     $ runqemu qemux86-64 core-image-minimal ext4
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -188,7 +188,7 @@
                             be installed (see the previous description for the
                             <filename>audio</filename> option for more information).
                             <literallayout class='monospaced'>
-     $ runqemu qemux86 ramfs audio
+     $ runqemu qemux86-64 ramfs audio
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -200,7 +200,7 @@
                             <replaceable>KERNEL</replaceable>, or
                             <replaceable>VM</replaceable> option.
                             <literallayout class='monospaced'>
-     $ runqemu ext3
+     $ runqemu ext4
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -209,9 +209,9 @@
                             From the <filename>.wic.vmdk</filename>,
                             <filename>runqemu</filename> determines the QEMU
                             architecture (<replaceable>MACHINE</replaceable>) to be
-                            "qemux86" and the root filesystem type to be "vmdk".
+                            "qemux86-64" and the root filesystem type to be "vmdk".
                             <literallayout class='monospaced'>
-     $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.wic.vmdk
+     $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk
                             </literallayout>
                             </para></listitem>
                     </itemizedlist>
@@ -296,7 +296,7 @@
                     extracts it to a directory named
                     <filename>test-nfs</filename>:
                     <literallayout class='monospaced'>
-     runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 test-nfs
+     runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
@@ -310,7 +310,7 @@
                     Here is an example using the <filename>qemux86</filename>
                     image:
                     <literallayout class='monospaced'>
-     runqemu qemux86 ./test-nfs
+     runqemu qemux86-64 ./test-nfs
                     </literallayout>
                     </para></listitem>
             </orderedlist>
diff --git a/poky/documentation/dev-manual/dev-manual-start.xml b/poky/documentation/dev-manual/dev-manual-start.xml
index 59ffa49bb..8cb5631f0 100644
--- a/poky/documentation/dev-manual/dev-manual-start.xml
+++ b/poky/documentation/dev-manual/dev-manual-start.xml
@@ -7,7 +7,7 @@
 <title>Setting Up to Use the Yocto Project</title>
 
 <para>
-    This chapter provides procedures related to getting set up to use the
+    This chapter provides guidance on how to prepare to use the
     Yocto Project.
     You can learn about creating a team environment that develops using the
     Yocto Project, how to set up a
@@ -24,9 +24,9 @@
         Project in a team development environment, or how to scale it for a
         large team of developers.
         You can adapt the Yocto Project to many different use cases and
-        scenarios.
-        However, this flexibility could cause difficulties if you are trying
-        to create a working setup that scales across a large team.
+        scenarios;
+        however, this flexibility could cause difficulties if you are trying
+        to create a working setup that scales effectively.
     </para>
 
     <para>
@@ -35,17 +35,17 @@
         that can help you get the results you want.
         The procedure is high-level and presents some of the project's most
         successful experiences, practices, solutions, and available
-        technologies that have proved to work well in the past.
-        Keep in mind, the procedure here is a starting point.
+        technologies that have proved to work well in the past;
+        however, keep in mind, the procedure here is simply a starting point.
         You can build off these steps and customize the procedure to fit any
         particular working environment and set of practices.
         <orderedlist>
             <listitem><para>
                 <emphasis>Determine Who is Going to be Developing:</emphasis>
-                You need to understand who is going to be doing anything
+                You first need to understand who is going to be doing anything
                 related to the Yocto Project and determine their roles.
                 Making this determination is essential to completing
-                steps two and three, which are to get your equipment together
+                subsequent steps, which are to get your equipment together
                 and set up your development environment's hardware topology.
                 </para>
 
@@ -64,8 +64,8 @@
                         <listitem><para>
                             <emphasis>Build Engineer:</emphasis>
                             This type of developer manages Autobuilders and
-                            releases.
-                            Not all environments need a Build Engineer.
+                            releases. Depending on the specifics of the environment,
+                            not all situations might need a Build Engineer.
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Test Engineer:</emphasis>
@@ -88,6 +88,11 @@
                 You can help ensure efficiency by having any machines used
                 for testing or that run Autobuilders be as high performance
                 as possible.
+                <note>
+                    Given sufficient processing power, you might also consider
+                    building Yocto Project development containers to be run
+                    under Docker, which is described later.
+                </note>
                 </para></listitem>
             <listitem><para>
                 <emphasis>Understand the Hardware Topology of the Environment:</emphasis>
@@ -114,10 +119,10 @@
                 and any software you are developing under the control of an SCM
                 system that is compatible   with the OpenEmbedded build system
                 is advisable.
-                Of the SCMs BitBake supports, the Yocto Project team strongly
+                Of all of the SCMs supported by BitBake, the Yocto Project team strongly
                 recommends using
                 <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>.
-                Git is a distributed system that is easy to backup,
+                Git is a distributed system that is easy to back up,
                 allows you to work remotely, and then connects back to the
                 infrastructure.
                 <note>
@@ -302,7 +307,7 @@
                 <para>As with any development environment, it is important
                 to document the policy used as well as any main project
                 guidelines so they are understood by everyone.
-                It is also a good idea to have well structured
+                It is also a good idea to have well-structured
                 commit messages, which are usually a part of a project's
                 guidelines.
                 Good commit messages are essential when looking back in time and
@@ -394,16 +399,18 @@
         This section provides procedures to set up a system to be used as your
         <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
         for development using the Yocto Project.
-        Your build host can be a native Linux machine (recommended) or it can
+        Your build host can be a native Linux machine (recommended), it can
         be a machine (Linux, Mac, or Windows) that uses
-        <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>,
+        <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>,
         which leverages
-        <ulink url='https://www.docker.com/'>Docker Containers</ulink>.
+        <ulink url='https://www.docker.com/'>Docker Containers</ulink> or it can
+        be a Windows machine capable of running Windows Subsystem For Linux v2 (WSL).
         <note>
-            You cannot use a build host that is using the
-            <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink>
-            (WSL).
-            The Yocto Project is not compatible with WSL.
+          The Yocto Project is not compatible with
+          <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux v1</ulink>.
+          It is compatible but not officially supported nor validated with WSLv2.
+          If you still decide to use WSL please upgrade to
+          <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-install'>WSLv2</ulink>.
         </note>
     </para>
 
@@ -442,7 +449,7 @@
                     You should have a reasonably current Linux-based host
                     system.
                     You will have the best results with a recent release of
-                    Fedora, openSUSE, Debian, Ubuntu, or CentOS as these
+                    Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS as these
                     releases are frequently tested against the Yocto Project
                     and officially supported.
                     For a list of the distributions under validation and their
@@ -460,23 +467,26 @@
                     <emphasis>Meet Minimal Version Requirements:</emphasis>
                     The OpenEmbedded build system should be able to run on any
                     modern distribution that has the following versions for
-                    Git, tar, and Python.
+                    Git, tar, Python and gcc.
                     <itemizedlist>
                         <listitem><para>
                             Git 1.8.3.1 or greater
                             </para></listitem>
                         <listitem><para>
-                            tar 1.27 or greater
+                            tar 1.28 or greater
                             </para></listitem>
                         <listitem><para>
-                            Python 3.4.0 or greater.
-                            </para></listitem>
+                            Python 3.5.0 or greater.
+                        </para></listitem>
+                        <listitem><para>
+                            gcc 5.0 or greater.
+                        </para></listitem>
                     </itemizedlist>
                     If your build host does not meet any of these three listed
                     version requirements, you can take steps to prepare the
                     system so that you can still use the Yocto Project.
                     See the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>"
                     section in the Yocto Project Reference Manual for
                     information.
                     </para></listitem>
@@ -517,7 +527,7 @@
 
         <para>
             With
-            <ulink url='https://github.com/crops/crops/blob/master/README.md'>CROPS</ulink>,
+            <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>,
             which leverages
             <ulink url='https://www.docker.com/'>Docker Containers</ulink>,
             you can create a Yocto Project development environment that
@@ -654,15 +664,147 @@
             section in the Toaster User Manual.
         </para>
     </section>
+
+    <section id='setting-up-to-use-wsl'>
+        <title>Setting Up to Use Windows Subsystem For Linux (WSLv2)</title>
+
+        <para>
+            With <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-about'>
+            Windows Subsystem for Linux (WSLv2)</ulink>, you can create a
+            Yocto Project development environment that allows you to build
+            on Windows. You can set up a Linux distribution inside Windows
+            in which you can develop using the Yocto Project.
+        </para>
+
+        <para>
+            Follow these general steps to prepare a Windows machine using WSLv2
+            as your Yocto Project build host:
+            <orderedlist>
+                <listitem><para>
+                    <emphasis>Make sure your Windows 10 machine is capable of running WSLv2:</emphasis>
+                  
+                    WSLv2 is only available for Windows 10 builds > 18917. To
+                    check which build version you are running, you may open a
+                    command prompt on Windows and execute the command "ver".
+                    <literallayout class='monospaced'>
+    C:\Users\myuser> ver
+
+    Microsoft Windows [Version 10.0.19041.153]
+                    </literallayout>
+                    If your build is capable of running WSLv2 you may continue,
+                    for more information on this subject or instructions on how
+                    to upgrade to WSLv2 visit <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-install'>Windows 10 WSLv2</ulink>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Install the Linux distribution of your choice inside Windows 10:</emphasis>
+                    Once you know your version of Windows 10 supports WSLv2,
+                    you can install the distribution of your choice from the
+                    Microsoft Store.
+                    Open the Microsoft Store and search for Linux. While there
+                    are several Linux distributions available, the assumption
+                    is that your pick will be one of the distributions supported
+                    by the Yocto Project as stated on the instructions for
+                    using a native Linux host.
+                    After making your selection, simply click "Get" to download
+                    and install the distribution.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Check your Linux distribution is using WSLv2:</emphasis>
+                    Open a Windows PowerShell and run:
+                    <literallayout class='monospaced'>
+    C:\WINDOWS\system32> wsl -l -v
+    NAME      STATE           VERSION
+    *Ubuntu    Running         2
+                    </literallayout>
+                    Note the version column which says the WSL version being used by
+                    your distribution, on compatible systems, this can be changed back
+                    at any point in time.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Optionally Orient Yourself on WSL:</emphasis>
+                    If you are unfamiliar with WSL, you can learn more here -
+                    <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-about'></ulink>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Launch your WSL Distibution:</emphasis>
+                    From the Windows start menu simply launch your WSL distribution
+                    just like any other application.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Optimize your WSLv2 storage often:</emphasis>
+                    Due to the way storage is handled on WSLv2, the storage
+                    space used by the undelying Linux distribution is not
+                    reflected immedately, and since bitbake heavily uses
+                    storage, after several builds, you may be unaware you
+                    are running out of space. WSLv2 uses a VHDX file for
+                    storage, this issue can be easily avoided by manually
+                    optimizing this file often, this can be done in the
+                    following way:
+                    <orderedlist>
+                        <listitem><para>
+                            <emphasis>Find the location of your VHDX file:</emphasis>
+                            First you need to find the distro app package directory,
+                            to achieve this open a Windows Powershell as Administrator
+                            and run:
+                            <literallayout class='monospaced'>
+    C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName
+    PackageFamilyName
+    -----------------
+    CanonicalGroupLimited.UbuntuonWindows_79abcdefgh
+                            </literallayout>
+                            You should now replace the <replaceable>PackageFamilyName</replaceable>
+                            and your <replaceable>user</replaceable> on the following
+                            path to find your VHDX file: <filename>C:\Users\user\AppData\Local\Packages\PackageFamilyName\LocalState\</filename>
+                            For example:
+                            <literallayout class='monospaced'>
+    ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\
+    Mode                 LastWriteTime         Length Name
+    -a----         3/14/2020   9:52 PM    57418973184 ext4.vhdx                      
+                            </literallayout>
+                            Your VHDX file path is: <filename>C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx</filename>
+                            </para></listitem>
+                        <listitem><para><emphasis>Optimize your VHDX file:</emphasis>
+                            Open a Windows Powershell as Administrator to optimize
+                            your VHDX file, shutting down WSL first:
+                            <literallayout class='monospaced'>
+    C:\WINDOWS\system32> wsl --shutdown
+    C:\WINDOWS\system32> optimize-vhd -Path C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full
+                            </literallayout>
+                            A progress bar should be shown while optimizing the VHDX file,
+                            and storage should now be reflected correctly on the Windows
+                            Explorer.
+                            </para></listitem>
+                    </orderedlist>
+                </para></listitem>
+            </orderedlist>
+            <note>
+              The current implementation of WSLv2 does not have out-of-the-box
+              access to external devices such as those connected through a
+              USB port, but it automatically mounts your <filename>C:</filename>
+              drive on <filename>/mnt/c/</filename> (and others), which
+              you can use to share deploy artifacts to be later flashed on
+              hardware through Windows, but your build directory should not
+              reside inside this mountpoint.
+            </note>
+            Once you have WSLv2 set up, everything is in place to
+            develop just as if you were running on a native Linux machine.
+            If you are going to use the Extensible SDK container, see the
+            "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>"
+            Chapter in the Yocto Project Application Development and the
+            Extensible Software Development Kit (eSDK) manual.
+            If you are going to use the Toaster container, see the
+            "<ulink url='&YOCTO_DOCS_TOAST_URL;#toaster-manual-setup-and-use'>Setting Up and Using Toaster</ulink>"
+            section in the Toaster User Manual.
+        </para>
+    </section>
 </section>
 
 <section id='locating-yocto-project-source-files'>
     <title>Locating Yocto Project Source Files</title>
 
     <para>
-        This section shows you how to locate and access the
-        source files that ship with the Yocto Project.
-        You establish and use these local files to work on projects.
+        This section shows you how to locate, fetch and configure the source
+        files you'll need to work with the Yocto Project.
         <note><title>Notes</title>
             <itemizedlist>
                 <listitem><para>
@@ -1019,20 +1161,18 @@
            .
            .
            .
-       remotes/origin/pyro
-       remotes/origin/pyro-next
-       remotes/origin/rocko
-       remotes/origin/rocko-next
-       remotes/origin/sumo
-       remotes/origin/sumo-next
        remotes/origin/thud
        remotes/origin/thud-next
        remotes/origin/warrior
+       remotes/origin/warrior-next
+       remotes/origin/zeus
+       remotes/origin/zeus-next
+       ... and so on ...
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Checkout the Branch:</emphasis>
-                    Checkout the development branch in which you want to work.
+                    <emphasis>Check out the Branch:</emphasis>
+                    Check out the development branch in which you want to work.
                     For example, to access the files for the Yocto Project
                     &DISTRO; Release (&DISTRO_NAME;), use the following command:
                     <literallayout class='monospaced'>
@@ -1118,7 +1258,7 @@
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Checkout the Branch:</emphasis>
+                    <emphasis>Check out the Branch:</emphasis>
                     <literallayout class='monospaced'>
      $ git checkout tags/&DISTRO_REL_TAG; -b my_yocto_&DISTRO;
      Switched to a new branch 'my_yocto_&DISTRO;'
diff --git a/poky/documentation/dev-manual/dev-manual.xml b/poky/documentation/dev-manual/dev-manual.xml
index 04fa1e4f9..6f86454ed 100644..100755
--- a/poky/documentation/dev-manual/dev-manual.xml
+++ b/poky/documentation/dev-manual/dev-manual.xml
@@ -22,18 +22,17 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
         <revhistory>
             <revision>
                 <revnumber>1.1</revnumber>
-                <date>6 October 2011</date>
+                <date>October 2011</date>
                 <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
             </revision>
             <revision>
@@ -57,11 +56,6 @@
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.6</revnumber>
                 <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
@@ -118,9 +112,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -144,7 +143,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -161,18 +160,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/kernel-dev/kernel-dev-common.xml b/poky/documentation/kernel-dev/kernel-dev-common.xml
index 2ea5d3f38..c1c2d6d70 100644
--- a/poky/documentation/kernel-dev/kernel-dev-common.xml
+++ b/poky/documentation/kernel-dev/kernel-dev-common.xml
@@ -89,8 +89,8 @@
                         <emphasis>Prepare Your <filename>local.conf</filename> File:</emphasis>
                         By default, the
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                        variable is set to "qemux86", which is fine if you are
-                        building for the QEMU emulator in 32-bit mode.
+                        variable is set to "qemux86-64", which is fine if you are
+                        building for the QEMU emulator in 64-bit mode.
                         However, if you are not, you need to set the
                         <filename>MACHINE</filename> variable appropriately in
                         your <filename>conf/local.conf</filename> file found in
@@ -104,10 +104,12 @@
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
                         variable to include kernel modules.</para>
 
-                        <para>This example uses the default "qemux86" for the
-                        <filename>MACHINE</filename> variable but needs to
-                        add the "kernel-modules":
+                        <para>In this example we wish to build for qemux86 so
+                        we must set the <filename>MACHINE</filename> variable
+                        to "qemux86" and also add the "kernel-modules". As described
+                        we do this by appending to <filename>conf/local.conf</filename>:
                         <literallayout class='monospaced'>
+     MACHINE = "qemux86"
      MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
                         </literallayout>
                         </para></listitem>
@@ -314,8 +316,8 @@
                         File:</emphasis>
                         By default, the
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                        variable is set to "qemux86", which is fine if you are
-                        building for the QEMU emulator in 32-bit mode.
+                        variable is set to "qemux86-64", which is fine if you are
+                        building for the QEMU emulator in 64-bit mode.
                         However, if you are not, you need to set the
                         <filename>MACHINE</filename> variable appropriately in
                         your <filename>conf/local.conf</filename> file found
@@ -329,10 +331,12 @@
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
                         variable to include kernel modules.</para>
 
-                        <para>This example uses the default "qemux86" for the
-                        <filename>MACHINE</filename> variable but needs to
-                        add the "kernel-modules":
+                        <para>In this example we wish to build for qemux86 so
+                        we must set the <filename>MACHINE</filename> variable
+                        to "qemux86" and also add the "kernel-modules". As described
+                        we do this by appending to <filename>conf/local.conf</filename>:
                         <literallayout class='monospaced'>
+     MACHINE = "qemux86"
      MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
                         </literallayout>
                         </para></listitem>
@@ -655,26 +659,22 @@
      KMACHINE_genericx86-64 ?= "common-pc-64"
      KBRANCH_edgerouter = "standard/edgerouter"
      KBRANCH_beaglebone = "standard/beaglebone"
-     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 
      SRCREV_machine_genericx86    ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
      SRCREV_machine_genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
      SRCREV_machine_edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
      SRCREV_machine_beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
-     SRCREV_machine_mpc8315e-rdb ?= "2d1d010240846d7bff15d1fcc0cb6eb8a22fc78a"
 
 
      COMPATIBLE_MACHINE_genericx86 = "genericx86"
      COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
      COMPATIBLE_MACHINE_edgerouter = "edgerouter"
      COMPATIBLE_MACHINE_beaglebone = "beaglebone"
-     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
      LINUX_VERSION_genericx86 = "4.12.7"
      LINUX_VERSION_genericx86-64 = "4.12.7"
      LINUX_VERSION_edgerouter = "4.12.10"
      LINUX_VERSION_beaglebone = "4.12.10"
-     LINUX_VERSION_mpc8315e-rdb = "4.12.10"
                 </literallayout>
                 This append file contains statements used to support
                 several BSPs that ship with the Yocto Project.
@@ -948,12 +948,14 @@
                 <literallayout class='monospaced'>
      KBUILD_DEFCONFIG_<replaceable>KMACHINE</replaceable> ?= <replaceable>defconfig_file</replaceable>
                 </literallayout>
-                Here is an example that appends the
-                <filename>KBUILD_DEFCONFIG</filename> variable with
-                "common-pc" and provides the path to the "in-tree"
-                <filename>defconfig</filename> file:
+                Here is an example that assigns the
+                <filename>KBUILD_DEFCONFIG</filename> variable based on
+                "raspberrypi2" and provides the path to the "in-tree"
+                <filename>defconfig</filename> file
+                to be used for a Raspberry Pi 2,
+                which is based on the Broadcom 2708/2709 chipset:
                 <literallayout class='monospaced'>
-     KBUILD_DEFCONFIG_common-pc ?= "/home/scottrif/configfiles/my_defconfig_file"
+     KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
                 </literallayout>
             </para>
 
diff --git a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml
index 6d675a6d5..62c68527d 100644
--- a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml
+++ b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml
@@ -543,7 +543,6 @@
      yocto-kernel-cache/features/kgdb/hardware.cfg
      yocto-kernel-cache/ktypes/base/hardware.cfg
      yocto-kernel-cache/bsp/mti-malta32/hardware.cfg
-     yocto-kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg
      yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
      yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
      yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
diff --git a/poky/documentation/kernel-dev/kernel-dev.xml b/poky/documentation/kernel-dev/kernel-dev.xml
index 4c5881b07..998fe4141 100644..100755
--- a/poky/documentation/kernel-dev/kernel-dev.xml
+++ b/poky/documentation/kernel-dev/kernel-dev.xml
@@ -22,11 +22,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
@@ -34,7 +33,7 @@
             <revision>
                 <revnumber>1.4</revnumber>
                 <date>April 2013</date>
-                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+                <revremark>The initial document released with the Yocto Project 1.4 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
@@ -42,11 +41,6 @@
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.6</revnumber>
                 <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
@@ -103,9 +97,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -127,7 +126,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -144,18 +143,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/mega-manual/mega-manual.xml b/poky/documentation/mega-manual/mega-manual.xml
index cd9a3da8f..e730f7259 100644..100755
--- a/poky/documentation/mega-manual/mega-manual.xml
+++ b/poky/documentation/mega-manual/mega-manual.xml
@@ -33,11 +33,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
@@ -45,7 +44,7 @@
             <revision>
                 <revnumber>1.8</revnumber>
                 <date>April 2015</date>
-                <revremark>Released with the Yocto Project 1.8 Release.</revremark>
+                <revremark>The initial document released with the Yocto Project 1.8 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>2.0</revnumber>
@@ -89,9 +88,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>
@@ -113,7 +117,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -130,18 +134,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
 
diff --git a/poky/documentation/overview-manual/overview-manual-development-environment.xml b/poky/documentation/overview-manual/overview-manual-development-environment.xml
index 2f1bd1610..36ebf8a32 100644
--- a/poky/documentation/overview-manual/overview-manual-development-environment.xml
+++ b/poky/documentation/overview-manual/overview-manual-development-environment.xml
@@ -87,7 +87,7 @@
         as its operating system as your development host.
         When you have a Mac or Windows-based system, you can set it up
         as the development host by using
-        <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>,
+        <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>,
         which leverages
         <ulink url='https://www.docker.com/'>Docker Containers</ulink>.
         Once you take the steps to set up a CROPS machine, you effectively
diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.xml b/poky/documentation/overview-manual/overview-manual-yp-intro.xml
index dbf62cc16..1b60a3030 100644
--- a/poky/documentation/overview-manual/overview-manual-yp-intro.xml
+++ b/poky/documentation/overview-manual/overview-manual-yp-intro.xml
@@ -225,9 +225,9 @@
                         For information that helps you transition from
                         trying out the Yocto Project to using it for your
                         project, see the
-                        "<ulink url='&YOCTO_HOME_URL;/docs/what-i-wish-id-known/'>What I wish I'd Known</ulink>"
+                        "<ulink url='&YOCTO_DOCS_URL;/what-i-wish-id-known/'>What I wish I'd Known</ulink>"
                         and
-                        "<ulink url='&YOCTO_HOME_URL;/docs/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>"
+                        "<ulink url='&YOCTO_DOCS_URL;/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>"
                         documents on the Yocto Project website.
                         </para></listitem>
                     <listitem><para>
@@ -437,7 +437,7 @@
                 <itemizedlist>
                     <listitem><para id='gs-crops-overview'>
                         <emphasis>CROPS:</emphasis>
-                        <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>
+                        <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>
                         is an open source, cross-platform development framework
                         that leverages
                         <ulink url='https://www.docker.com/'>Docker Containers</ulink>.
@@ -883,7 +883,7 @@
                 <listitem><para>
                     <emphasis>CROss PlatformS (CROPS):</emphasis>
                     Typically, you use
-                    <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>,
+                    <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>,
                     which leverages
                     <ulink url='https://www.docker.com/'>Docker Containers</ulink>,
                     to set up a Build Host that is not running Linux (e.g.
@@ -908,6 +908,24 @@
                     section in the Yocto Project Development Tasks Manual.
                     </para></listitem>
                 <listitem><para>
+                    <emphasis>Windows Subsystem For Linux (WSLv2):</emphasis>
+                    You may use Windows Subsystem For Linux v2 to set up a build
+                    host using Windows 10.
+                    <note>
+                      The Yocto Project is not compatible with WSLv1, it is
+                      compatible but not officially supported nor validated
+                      with WSLv2, if you still decide to use WSL please upgrade
+                      to WSLv2.
+                    </note>
+                    The Windows Subsystem For Linux allows Windows 10 to run a real
+                    Linux kernel inside of a lightweight utility virtual
+                    machine (VM) using virtualization technology.</para>
+                    <para>For information on how to set up a Build Host with
+                    WSLv2, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>"
+                    section in the Yocto Project Development Tasks Manual.
+                    </para></listitem>
+                <listitem><para>
                     <emphasis>Toaster:</emphasis>
                     Regardless of what your Build Host is running, you can
                     use Toaster to develop software using the Yocto Project.
diff --git a/poky/documentation/overview-manual/overview-manual.xml b/poky/documentation/overview-manual/overview-manual.xml
index c7716e460..210d644b3 100644..100755
--- a/poky/documentation/overview-manual/overview-manual.xml
+++ b/poky/documentation/overview-manual/overview-manual.xml
@@ -22,11 +22,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
@@ -39,7 +38,7 @@
             <revision>
                 <revnumber>2.6</revnumber>
                 <date>November 2018</date>
-                <revremark>Released with the Yocto Project 2.7 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>2.7</revnumber>
@@ -48,9 +47,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -74,7 +78,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -91,18 +95,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/poky.ent b/poky/documentation/poky.ent
index 7af47df72..a54793911 100644..100755
--- a/poky/documentation/poky.ent
+++ b/poky/documentation/poky.ent
@@ -1,19 +1,21 @@
-<!ENTITY DISTRO "3.0">
-<!ENTITY DISTRO_COMPRESSED "30">
-<!ENTITY DISTRO_NAME_NO_CAP "zeus">
-<!ENTITY DISTRO_NAME "Zeus">
-<!ENTITY DISTRO_NAME_NO_CAP_MINUS_ONE "warrior">
-<!ENTITY DISTRO_NAME_MINUS_ONE "Warrior">
-<!ENTITY YOCTO_DOC_VERSION "3.0">
-<!ENTITY YOCTO_DOC_VERSION_MINUS_ONE "2.7">
-<!ENTITY DISTRO_REL_TAG "yocto-3.0">
-<!ENTITY METAINTELVERSION "9.0">
-<!ENTITY REL_MONTH_YEAR "October 2019">
+<!ENTITY DISTRO "3.1">
+<!ENTITY DISTRO_COMPRESSED "31">
+<!ENTITY DISTRO_NAME_NO_CAP "dunfell">
+<!ENTITY DISTRO_NAME "Dunfell">
+<!ENTITY DISTRO_NAME_NO_CAP_MINUS_ONE "zeus">
+<!ENTITY DISTRO_NAME_MINUS_ONE "Zeus">
+<!ENTITY YOCTO_DOC_VERSION "3.1">
+<!ENTITY YOCTO_DOC_VERSION_MINUS_ONE "3.0.2">
+<!ENTITY DISTRO_REL_TAG "yocto-3.1">
+<!ENTITY METAINTELVERSION "12.0">
+<!ENTITY REL_MONTH_YEAR "April 2020">
 <!ENTITY META_INTEL_REL_TAG "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;">
-<!ENTITY POKYVERSION "22.0.0">
-<!ENTITY POKYVERSION_COMPRESSED "2200">
+<!ENTITY POKYVERSION "23.0.0">
+<!ENTITY POKYVERSION_COMPRESSED "2300">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2019">
+<!ENTITY COPYRIGHT_YEAR "2010-2020">
+<!ENTITY ORGNAME "The Yocto Project">
+<!ENTITY ORGEMAIL "docs@lists.yoctoproject.org">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -58,22 +60,30 @@
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
 <!ENTITY OE_INIT_FILE "oe-init-build-env">
 <!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo gcc-multilib \
-     build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
+     build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
      xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
      pylint3 xterm">
 <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python3 unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
      ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
      python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython \
-     python3-jinja2 SDL-devel xterm">
+     python3-jinja2 SDL-devel xterm rpcgen">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
-     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
-     $ sudo pip3 install GitPython libSDL-devel xterm">
-<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
+     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm rpcgen
+     $ sudo pip3 install GitPython">
+<!ENTITY CENTOS7_HOST_PACKAGES_ESSENTIAL "-y epel-release
      $ sudo yum makecache
-     $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
+     $ sudo yum install gawk make wget tar bzip2 gzip python3 unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
-     perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python34-pip xz \
+     perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python36-pip xz \
      which SDL-devel xterm
      $ sudo pip3 install GitPython jinja2">
+<!ENTITY CENTOS8_HOST_PACKAGES_ESSENTIAL "-y epel-release
+     $ sudo dnf config-manager --set-enabled PowerTools
+     $ sudo dnf makecache
+     $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
+     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache \
+     socat perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip \
+     python3-GitPython python3-jinja2 python3-pexpect xz which SDL-devel xterm \
+     rpcgen">
diff --git a/poky/documentation/profile-manual/profile-manual-usage.xml b/poky/documentation/profile-manual/profile-manual-usage.xml
index 5999b2960..9a4273a0f 100644
--- a/poky/documentation/profile-manual/profile-manual-usage.xml
+++ b/poky/documentation/profile-manual/profile-manual-usage.xml
@@ -2182,7 +2182,7 @@
               meta-toolchain
               meta-ide-support
 
-     You can also run generated qemu images with a command like 'runqemu qemux86'
+     You can also run generated qemu images with a command like 'runqemu qemux86-64'
 
             </literallayout>
             Once you've done that, you can cd to whatever directory
diff --git a/poky/documentation/profile-manual/profile-manual.xml b/poky/documentation/profile-manual/profile-manual.xml
index c1f461f43..fa1fa8ac8 100644..100755
--- a/poky/documentation/profile-manual/profile-manual.xml
+++ b/poky/documentation/profile-manual/profile-manual.xml
@@ -22,11 +22,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
@@ -34,7 +33,7 @@
             <revision>
                 <revnumber>1.4</revnumber>
                 <date>April 2013</date>
-                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+                <revremark>The initial document released with the Yocto Project 1.4 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
@@ -42,11 +41,6 @@
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.6</revnumber>
                 <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
@@ -103,9 +97,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -129,7 +128,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -146,18 +145,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/ref-manual/faq.xml b/poky/documentation/ref-manual/faq.xml
index 49ff86261..d94cb32a8 100644
--- a/poky/documentation/ref-manual/faq.xml
+++ b/poky/documentation/ref-manual/faq.xml
@@ -33,7 +33,7 @@
             <para id='faq-not-meeting-requirements'>
                 My development system does not meet the
                 required Git, tar, and Python versions.
-                In particular, I do not have Python 3.4.0 or greater.
+                In particular, I do not have Python 3.5.0 or greater.
                 Can I still use the Yocto Project?
             </para>
         </question>
@@ -43,7 +43,7 @@
                 system a couple different ways (i.e. building a tarball or
                 downloading a tarball).
                 See the
-                "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+                "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>"
                 section for steps on how to update your build tools.
             </para>
         </answer>
diff --git a/poky/documentation/ref-manual/migration.xml b/poky/documentation/ref-manual/migration.xml
index 8d50ab913..9422b5a27 100644
--- a/poky/documentation/ref-manual/migration.xml
+++ b/poky/documentation/ref-manual/migration.xml
@@ -680,7 +680,7 @@
 
         <para>
             For more information on this requirement, see the
-            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>"
             section.
         </para>
     </section>
@@ -1754,7 +1754,7 @@
             Git that meets this requirement, you can use the
             <filename>buildtools-tarball</filename> that does.
             See the
-            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>"
             section for more information.
         </para>
     </section>
@@ -2110,7 +2110,7 @@
             such as the following:
             <literallayout class='monospaced'>
      inherit bluetooth
-     PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
+     PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
      PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
      PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
             </literallayout>
@@ -3215,7 +3215,7 @@
                     recent version, you can install the buildtools, which
                     will provide it.
                     See the
-                    "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+                    "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>"
                     section for more information on the buildtools tarball.
                     </para></listitem>
                 <listitem><para>
@@ -3624,7 +3624,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
             image types, this part of the kernel image base name as been
             removed leaving only the following:
             <literallayout class='monospaced'>
-     KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}
+     KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
             </literallayout>
             If you have recipes or classes that use
             <filename>KERNEL_IMAGE_BASE_NAME</filename> directly, you might
@@ -5601,7 +5601,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
                     creation time, use
                     <filename>pkg_postinst_ontarget()</filename>
                     or call
-                    <filename>postinst-intercepts defer_to_first_boot</filename>
+                    <filename>postinst_intercept delay_to_first_boot</filename>
                     from <filename>pkg_postinst()</filename>.
                     Any failure of a <filename>pkg_postinst()</filename>
                     script (including <filename>exit 1</filename>)
@@ -6192,7 +6192,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
             If you want to explicitly defer a postinstall to first boot on
             the target rather than at rootfs creation time, use
             <filename>pkg_postinst_ontarget()</filename> or call
-            <filename>postinst-intercepts defer_to_first_boot</filename> from
+            <filename>postinst_intercept delay_to_first_boot</filename> from
             <filename>pkg_postinst()</filename>.
             Any failure of a <filename>pkg_postinst()</filename> script
             (including exit 1) triggers an error during the
@@ -7095,6 +7095,207 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
     </section>
 </section>
 
+
+<section id='moving-to-the-yocto-project-3.1-release'>
+    <title>Moving to the Yocto Project 3.1 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 3.1 Release from the prior release.
+    </para>
+
+    <section id='migration-3.1-minimum-system-requirements'>
+        <title>Minimum system requirements</title>
+
+        <para>
+            The following versions / requirements of build host components have been updated:
+            <itemizedlist>
+                <listitem><para>gcc 5.0</para></listitem>
+                <listitem><para>python 3.5</para></listitem>
+                <listitem><para>tar 1.28</para></listitem>
+                <listitem><para><filename>rpcgen</filename> is now required on the host (part of the <filename>libc-dev-bin</filename> package on Ubuntu, Debian and related distributions, and the <filename>glibc</filename> package on RPM-based distributions).</para></listitem>
+            </itemizedlist>
+            
+            Additionally, the <filename>makeinfo</filename> and <filename>pod2man</filename>
+            tools are <emphasis>no longer</emphasis> required on the host.
+        </para>
+    </section>
+
+    <section id='migration-3.1-mpc8315e-rdb-removed'>
+        <title>mpc8315e-rdb machine removed</title>
+
+        <para>
+            The MPC8315E-RDB machine is old/obsolete and unobtainable, thus given the maintenance burden
+            the <filename>mpc8315e-rdb</filename> machine configuration that supported it has been removed
+            in this release. The removal does leave a gap in official PowerPC reference hardware
+            support; this may change in future if a suitable machine with accompanying support resources
+            is found.
+        </para>
+    </section>
+    
+    <section id='migration-3.1-python-2-removed'>
+        <title>Python 2 removed</title>
+
+        <para>
+            Due to the expiration of upstream support in January 2020, support for Python 2 has now been removed; it is recommended that you use Python 3 instead. If absolutely needed there is a meta-python2 community layer containing Python 2, related classes and various Python 2-based modules, however it should not be considered as supported.
+        </para>
+    </section>
+
+    <section id='migration-3.1-reproducible-builds'>
+        <title>Reproducible builds now enabled by default</title>
+
+        <para>
+            In order to avoid unnecessary differences in output files (aiding binary reproducibility), the Poky distribution configuration (<filename><link linkend='var-DISTRO'>DISTRO</link> = "poky"</filename>) now inherits the <filename>reproducible_build</filename> class by default.
+        </para>
+    </section>
+    
+    <section id='migration-3.1-ptest-feature-impact'>
+        <title>Impact of ptest feature is now more significant</title>
+
+        <para>
+            The Poky distribution configuration (<filename><link linkend='var-DISTRO'>DISTRO</link> = "poky"</filename>) enables ptests by default to enable runtime testing of various components. In this release, a dependency needed to be added that has resulted in a significant increase in the number of components that will be built just when building a simple image such as core-image-minimal. If you do not need runtime tests enabled for core components, then it is recommended that you remove "ptest" from <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> to save a significant amount of build time e.g. by adding the following in your configuration:
+
+            <literallayout class='monospaced'>
+      DISTRO_FEATURES_remove = "ptest"
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-3.1-removed-recipes'>
+        <title>Removed recipes</title>
+
+        <para>
+            The following recipes have been removed:
+
+            <itemizedlist>
+                <listitem><para><filename>chkconfig</filename>: obsolete</para></listitem>
+                <listitem><para><filename>console-tools</filename>: obsolete</para></listitem>
+                <listitem><para><filename>enchant</filename>: replaced by <filename>enchant2</filename></para></listitem>
+                <listitem><para><filename>foomatic-filters</filename>: obsolete</para></listitem>
+                <listitem><para><filename>libidn</filename>: no longer needed, moved to meta-oe</para></listitem>
+                <listitem><para><filename>libmodulemd</filename>: replaced by <filename>libmodulemd-v1</filename></para></listitem>
+                <listitem><para><filename>linux-yocto</filename>: drop 4.19, 5.2 version recipes (5.4 now provided)</para></listitem>
+                <listitem><para><filename>nspr</filename>: no longer needed, moved to meta-oe</para></listitem>
+                <listitem><para><filename>nss</filename>: no longer needed, moved to meta-oe</para></listitem>
+                <listitem><para><filename>python</filename>: Python 2 removed (Python 3 preferred)</para></listitem>
+                <listitem><para><filename>python-setuptools</filename>: Python 2 version removed (python3-setuptools preferred)</para></listitem>
+                <listitem><para><filename>sysprof</filename>: no longer needed, moved to meta-oe</para></listitem>
+                <listitem><para><filename>texi2html</filename>: obsolete</para></listitem>
+                <listitem><para><filename>u-boot-fw-utils</filename>: functionally replaced by <filename>libubootenv</filename></para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-3.1-features-check'>
+        <title>features_check class replaces distro_features_check</title>
+
+        <para>
+            The <filename>distro_features_check</filename> class has had its functionality expanded, now supporting <filename>ANY_OF_MACHINE_FEATURES</filename>, <filename>REQUIRED_MACHINE_FEATURES</filename>, <filename>CONFLICT_MACHINE_FEATURES</filename>, <filename>ANY_OF_COMBINED_FEATURES</filename>, <filename>REQUIRED_COMBINED_FEATURES</filename>, <filename>CONFLICT_COMBINED_FEATURES</filename>. As a result the class has now been renamed to <filename>features_check</filename>; the <filename>distro_features_check</filename> class still exists but generates a warning and redirects to the new class. In preparation for a future removal of the old class it is recommended that you update recipes currently inheriting <filename>distro_features_check</filename> to inherit <filename>features_check</filename> instead.
+        </para>
+    </section>
+
+    <section id='migration-3.1-removed-classes'>
+        <title>Removed classes</title>
+
+        <para>
+            The following classes have been removed:
+
+            <itemizedlist>
+                <listitem><para><filename>distutils-base</filename>: moved to meta-python2</para></listitem>
+                <listitem><para><filename>distutils</filename>: moved to meta-python2</para></listitem>
+                <listitem><para><filename>libc-common</filename>: merged into the glibc recipe as nothing else used it.</para></listitem>
+                <listitem><para><filename>python-dir</filename>: moved to meta-python2</para></listitem>
+                <listitem><para><filename>pythonnative</filename>: moved to meta-python2</para></listitem>
+                <listitem><para><filename>setuptools</filename>: moved to meta-python2</para></listitem>
+                <listitem><para><filename>tinderclient</filename>: dropped as it was obsolete.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-3.1-src-uri-checksums'>
+        <title>SRC_URI checksum behaviour</title>
+
+        <para>
+            Previously, recipes by tradition included both SHA256 and MD5 checksums for remotely fetched files in <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, even though only one is actually mandated. However, the MD5 checksum does not add much given its inherent weakness; thus when a checksum fails only the SHA256 sum will now be printed. The md5sum will still be verified if it is specified.
+        </para>
+    </section>
+
+
+    <section id='migration-3.1-npm'>
+        <title>npm fetcher changes</title>
+
+        <para>
+            The npm fetcher has been completely reworked in this release. The npm fetcher now only fetches the package source itself and no longer the dependencies; there is now also an npmsw fetcher which explicitly fetches the shrinkwrap file and the dependencies. This removes the slightly awkward <filename>NPM_LOCKDOWN</filename> and <filename>NPM_SHRINKWRAP</filename> variables which pointed to local files; the lockdown file is no longer needed at all. Additionally, the package name in <filename>npm://</filename> entries in <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> is now specified using a <filename>package</filename> parameter instead of the earlier <filename>name</filename> which overlapped with the generic <filename>name</filename> parameter. All recipes using the npm fetcher will need to be changed as a result. 
+        </para>
+        <para>
+            An example of the new scheme:
+            <literallayout class='monospaced'>
+SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \
+           npmsw://${THISDIR}/npm-shrinkwrap.json"
+            </literallayout>
+            Another example where the sources are fetched from git rather than an npm repository:
+            <literallayout class='monospaced'>
+SRC_URI = "git://github.com/foo/bar.git;protocol=https \
+           npmsw://${THISDIR}/npm-shrinkwrap.json"
+            </literallayout>
+        </para>
+        <para>
+            devtool and recipetool have also been updated to match with the npm fetcher changes. Other than producing working and more complete recipes for npm sources, there is also a minor change to the command line for devtool: the <filename>--fetch-dev</filename> option has been renamed to <filename>--npm-dev</filename> as it is npm-specific.
+        </para>
+    </section>
+    
+    
+    <section id='migration-3.1-packaging-changes'>
+        <title>Packaging changes</title>
+
+        <para>
+            <itemizedlist>
+                <listitem><para><filename>intltool</filename> has been removed from <filename>packagegroup-core-sdk</filename> as it is rarely needed to build modern software - gettext can do most of the things it used to be needed for. <filename>intltool</filename> has also been removed from <filename>packagegroup-core-self-hosted</filename> as it is not needed to for standard builds.</para></listitem>
+                <listitem><para>git: <filename>git-am</filename>, <filename>git-difftool</filename>, <filename>git-submodule</filename>, and <filename>git-request-pull</filename> are no longer perl-based, so are now installed with the main <filename>git</filename> package instead of within <filename>git-perltools</filename>.</para></listitem>
+                <listitem><para>The <filename>ldconfig</filename> binary built as part of glibc has now been moved to its own <filename>ldconfig</filename> package (note no <filename>glibc-</filename> prefix). This package is in the <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> of the main <filename>glibc</filename> package if <filename>ldconfig</filename> is present in <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.</para></listitem>
+                <listitem><para><filename>libevent</filename> now splits each shared library into its own package (as Debian does). Since these are shared libraries and will be pulled in through the normal shared library dependency handling, there should be no impact to existing configurations other than less unnecessary libraries being installed in some cases.</para></listitem>
+                <listitem><para>linux-firmware now has a new package for <filename>bcm4366c</filename> and includes available NVRAM config files into the <filename>bcm43340</filename>, <filename>bcm43362</filename>, <filename>bcm43430</filename> and <filename>bcm4356-pcie</filename> packages.</para></listitem>
+                <listitem><para><filename>harfbuzz</filename> now splits the new <filename>libharfbuzz-subset.so</filename> library into its own package to reduce the main package size in cases where <filename>libharfbuzz-subset.so</filename> is not needed.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+    
+    <section id='migration-3.1-package-qa-warnings'>
+        <title>Additional warnings</title>
+
+        <para>
+            Warnings will now be shown at <filename>do_package_qa</filename> time in the following circumstances:
+            
+            <itemizedlist>
+                <listitem><para>A recipe installs <filename>.desktop</filename> files containing <filename>MimeType</filename> keys but does not inherit the new <filename>mime-xdg</filename> class</para></listitem>
+                <listitem><para>A recipe installs <filename>.xml</filename> files into <filename>${datadir}/mime/packages</filename> but does not inherit the <filename>mime</filename> class</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+        
+    <section id='migration-3.1-x86-live-wic'>
+        <title><filename>wic</filename> image type now used instead of <filename>live</filename> by default for x86</title>
+
+        <para>
+            <filename>conf/machine/include/x86-base.inc</filename> (inherited by most x86 machine configurations) now specifies <filename>wic</filename> instead of <filename>live</filename> by default in <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>. The <filename>live</filename> image type will likely be removed in a future release so it is recommended that you use <filename>wic</filename> instead.
+        </para>
+    </section>
+                
+    <section id='migration-3.1-misc'>
+        <title>Miscellaneous changes</title>
+
+        <para>
+            <itemizedlist>
+                <listitem><para>The undocumented <filename>SRC_DISTRIBUTE_LICENSES</filename> variable has now been removed in favour of a new <filename>AVAILABLE_LICENSES</filename> variable which is dynamically set based upon license files found in <filename>${COMMON_LICENSE_DIR}</filename> and <filename>${LICENSE_PATH}</filename>.</para></listitem>
+                <listitem><para>The tune definition for big-endian microblaze machines is now <filename>microblaze</filename> instead of <filename>microblazeeb</filename>.</para></listitem>
+                <listitem><para><filename>newlib</filename> no longer has built-in syscalls. <filename>libgloss</filename> should then provide the syscalls, <filename>crt0.o</filename> and other functions that are no longer part of <filename>newlib</filename> itself. If you are using <filename>TCLIBC = "newlib"</filename> this now means that you must link applications with both <filename>newlib</filename> and <filename>libgloss</filename>, whereas before <filename>newlib</filename> would run in many configurations by itself.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+</section>
+
+
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4
diff --git a/poky/documentation/ref-manual/ref-features.xml b/poky/documentation/ref-manual/ref-features.xml
index 44ba67cf5..294b297c2 100644
--- a/poky/documentation/ref-manual/ref-features.xml
+++ b/poky/documentation/ref-manual/ref-features.xml
@@ -210,6 +210,12 @@
                 <listitem><para><emphasis>usbhost:</emphasis> Include USB Host
                     support (allows to connect external keyboard, mouse,
                     storage, network etc).</para></listitem>
+                <listitem><para><emphasis>usrmerge:</emphasis> Merges the 
+                    <filename>/bin</filename>, <filename>/sbin</filename>, 
+                    <filename>/lib</filename>, and <filename>/lib64</filename>       
+                    directories into their respective counterparts in the 
+                    <filename>/usr</filename> directory to provide better package 
+                   and application compatibility.</para></listitem>
                 <listitem><para><emphasis>wayland:</emphasis> Include the
                     Wayland display server protocol and the library that
                     supports it.</para></listitem>
diff --git a/poky/documentation/ref-manual/ref-manual.xml b/poky/documentation/ref-manual/ref-manual.xml
index b442f709a..9a914f19c 100644..100755
--- a/poky/documentation/ref-manual/ref-manual.xml
+++ b/poky/documentation/ref-manual/ref-manual.xml
@@ -22,11 +22,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
 
         </authorgroup>
@@ -34,22 +33,17 @@
         <revhistory>
             <revision>
                 <revnumber>4.0+git</revnumber>
-                <date>24 November 2010</date>
-                <revremark>Released with the Yocto Project 0.9 Release</revremark>
+                <date>November 2010</date>
+                <revremark>The initial document released with the Yocto Project 0.9 Release</revremark>
             </revision>
             <revision>
                 <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
+                <date>April 2011</date>
                 <revremark>Released with the Yocto Project 1.0 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.0.1</revnumber>
-                <date>23 May 2011</date>
-                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.1</revnumber>
-                <date>6 October 2011</date>
+                <date>October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
             <revision>
@@ -73,11 +67,6 @@
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.6</revnumber>
                 <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
@@ -134,9 +123,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -158,7 +152,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -175,18 +169,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/ref-manual/ref-structure.xml b/poky/documentation/ref-manual/ref-structure.xml
index 8e0c9f5b6..27f17dd91 100644
--- a/poky/documentation/ref-manual/ref-structure.xml
+++ b/poky/documentation/ref-manual/ref-structure.xml
@@ -8,11 +8,11 @@
 
 <para>
     The <link linkend='source-directory'>Source Directory</link>
-    consists of several components.
-    Understanding them and knowing where they are located is key to using the
-    Yocto Project well.
+    consists of numerous files, directories and subdirectories;
+    understanding their locations and contents is key to using the
+    Yocto Project effectively.
     This chapter describes the Source Directory and gives information about
-    the various files and directories.
+    those files and directories.
 </para>
 
 <para>
@@ -22,12 +22,12 @@
     section in the Yocto Project Development Tasks Manual.
 </para>
 
-<note>
-    The OpenEmbedded build system does not support file or directory names that
-    contain spaces.
-    Be sure that the Source Directory you use does not contain these types
-    of names.
-</note>
+    <note>
+        The OpenEmbedded build system does not support file or directory names that
+        contain spaces.
+        Be sure that the Source Directory you use does not contain these types
+        of names.
+    </note>
 
 <section id='structure-core'>
     <title>Top-Level Core Components</title>
@@ -48,18 +48,18 @@
             <link linkend='metadata'>Metadata</link>
             interpreter, reads the Yocto Project Metadata and runs the tasks
             defined by that data.
-            Failures are usually from the Metadata and not from BitBake itself.
-            Consequently, most users do not need to worry about BitBake.
+            Failures are usually caused by errors in your Metadata and not from BitBake itself;
+            consequently, most users do not need to worry about BitBake.
         </para>
 
         <para>
             When you run the <filename>bitbake</filename> command, the
-            main BitBake executable, which resides in the
-            <filename>bitbake/bin/</filename> directory, starts.
+            main BitBake executable (which resides in the
+            <filename>bitbake/bin/</filename> directory) starts.
             Sourcing the environment setup script (i.e.
             <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>)
-            places the <filename>scripts</filename> and
-            <filename>bitbake/bin</filename> directories (in that order) into
+            places the <filename>scripts/</filename> and
+            <filename>bitbake/bin/</filename> directories (in that order) into
             the shell's <filename>PATH</filename> environment variable.
         </para>
 
@@ -91,7 +91,7 @@
             by providing a directory name when you <filename>source</filename>
             the setup script.
             For information on separating output from your local
-            Source Directory files, see the
+            Source Directory files (commonly described as an "out of tree" build), see the
             "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
             section.
         </para>
@@ -104,8 +104,8 @@
             This directory holds the source for the Yocto Project documentation
             as well as templates and tools that allow you to generate PDF and HTML
             versions of the manuals.
-            Each manual is contained in a sub-folder.
-            For example, the files for this manual reside in
+            Each manual is contained in its own sub-folder;
+            for example, the files for this reference manual reside in
             the <filename>ref-manual/</filename> directory.
         </para>
     </section>
@@ -114,9 +114,9 @@
         <title><filename>meta/</filename></title>
 
         <para>
-            This directory contains the OpenEmbedded-Core metadata.
+            This directory contains the minimal, underlying OpenEmbedded-Core metadata.
             The directory holds recipes, common classes, and machine
-            configuration for emulated targets (<filename>qemux86</filename>,
+            configuration for strictly emulated targets (<filename>qemux86</filename>,
             <filename>qemuarm</filename>, and so forth.)
         </para>
     </section>
@@ -125,8 +125,8 @@
         <title><filename>meta-poky/</filename></title>
 
         <para>
-            This directory contains the configuration for the Poky
-            reference distribution.
+            Designed above the <filename>meta/</filename> content, this directory
+            adds just enough metadata to define the Poky reference distribution.
         </para>
     </section>
 
@@ -148,9 +148,6 @@
             This directory adds additional recipes and append files
             used by the OpenEmbedded selftests to verify the behavior
             of the build system.
-        </para>
-
-        <para>
             You do not have to add this layer to your
             <filename>bblayers.conf</filename> file unless you want to run the
             selftests.
@@ -172,7 +169,7 @@
             This directory contains various integration scripts that implement
             extra functionality in the Yocto Project environment (e.g. QEMU scripts).
             The <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
-            script appends this directory to the shell's
+            script prepends this directory to the shell's
             <filename>PATH</filename> environment variable.
         </para>
 
@@ -202,7 +199,8 @@
             up, a
             <link linkend='build-directory'>Build Directory</link>
             is created, your working directory becomes the Build Directory,
-            and you are presented with a list of common BitBake targets.
+            and you are presented with some simple suggestions as to what to do
+            next, including a list of some possible targets to build.
             Here is an example:
             <literallayout class='monospaced'>
      $ source oe-init-build-env
@@ -217,14 +215,14 @@
          meta-toolchain
          meta-ide-support
 
-     You can also run generated qemu images with a command like 'runqemu qemux86'
+     You can also run generated qemu images with a command like 'runqemu qemux86-64'
             </literallayout>
-            The script gets its default list of common targets from the
-            <filename>conf-notes.txt</filename> file, which is found in the
+            The default output of the <filename>oe-init-build-env</filename> script
+            is from the <filename>conf-notes.txt</filename> file, which is found in the
             <filename>meta-poky</filename> directory within the
             <link linkend='source-directory'>Source Directory</link>.
-            Should you have custom distributions, it is very easy to modify
-            this configuration file to include your targets for your
+            If you design a custom distribution, you can include your own version
+            of this configuration file to mention the targets defined by your
             distribution.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
@@ -234,20 +232,20 @@
 
         <para>
             By default, running this script without a Build Directory
-            argument creates the <filename>build</filename> directory
+            argument creates the <filename>build/</filename> directory
             in your current working directory.
             If you provide a Build Directory argument when you
             <filename>source</filename> the script, you direct the OpenEmbedded
             build system to create a Build Directory of your choice.
             For example, the following command creates a Build Directory named
-            <filename>mybuilds</filename> that is outside of the
+            <filename>mybuilds/</filename> that is outside of the
             <link linkend='source-directory'>Source Directory</link>:
             <literallayout class='monospaced'>
      $ source &OE_INIT_FILE; ~/mybuilds
             </literallayout>
             The OpenEmbedded build system uses the template configuration
             files, which are found by default in the
-            <filename>meta-poky/conf</filename> directory in the
+            <filename>meta-poky/conf/</filename> directory in the
             Source Directory.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
@@ -280,28 +278,26 @@
     <para>
         The OpenEmbedded build system creates the
         <link linkend='build-directory'>Build Directory</link>
-        when you run the build environment setup scripts (i.e.
-        <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
-    </para>
-
-    <para>
+        when you run the build environment setup script
+        <link
+linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>.
         If you do not give the Build Directory a specific name when you run
-        a setup script, the name defaults to <filename>build</filename>.
+        the setup script, the name defaults to <filename>build/</filename>.
     </para>
 
     <para>
-        The
-        <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link> variable
-        points to the Build Directory.
+        For subsequent parsing and processing, the name of the Build
+        directory is available via the
+        <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link> variable.
     </para>
 
     <section id='structure-build-buildhistory'>
-        <title><filename>build/buildhistory</filename></title>
+        <title><filename>build/buildhistory/</filename></title>
 
         <para>
             The OpenEmbedded build system creates this directory when you
-            enable the build history feature.
-            The directory tracks build information into image, packages, and
+            enable build history via the <filename>buildhistory</filename> class file.
+            The directory organizes build information into image, packages, and
             SDK subdirectories.
             For information on the build history feature, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
@@ -320,14 +316,14 @@
             Any variable set here overrides any variable set elsewhere within
             the environment unless that variable is hard-coded within a file
             (e.g. by using '=' instead of '?=').
-            Some variables are hard-coded for various reasons but these
+            Some variables are hard-coded for various reasons but such
             variables are relatively rare.
         </para>
 
         <para>
-            Edit this file to set the
-            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
-            for which you want to build, which package types you wish to use
+            At a minimum, you would normally edit this file to select the target
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>,
+            which package types you wish to use
             (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
             and the location from which you want to access downloaded files
             (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>).
@@ -338,16 +334,16 @@
             start the build, the OpenEmbedded build system creates it from
             <filename>local.conf.sample</filename> when
             you <filename>source</filename> the top-level build environment
-            setup script (i.e.
-            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
+            setup script
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>.
         </para>
 
         <para>
             The source <filename>local.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-poky/conf</filename>
+            which defaults to <filename>meta-poky/conf/</filename>
             when you are building from the Yocto Project development
-            environment and defaults to <filename>meta/conf</filename> when
+            environment, and to <filename>meta/conf/</filename> when
             you are building from the OpenEmbedded-Core environment.
             Because the script variable points to the source of the
             <filename>local.conf.sample</filename> file, this implies that
@@ -395,11 +391,12 @@
         </para>
 
         <para>
-            The source <filename>bblayers.conf.sample</filename> file used
+            As with the <filename>local.conf</filename> file,
+            the source <filename>bblayers.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-poky/conf</filename>
+            which defaults to <filename>meta-poky/conf/</filename>
             when you are building from the Yocto Project development
-            environment and defaults to <filename>meta/conf</filename> when
+            environment, and to <filename>meta/conf/</filename> when
             you are building from the OpenEmbedded-Core environment.
             Because the script variable points to the source of the
             <filename>bblayers.conf.sample</filename> file, this implies that
@@ -418,13 +415,13 @@
                 <link linkend='source-directory'>Source Directory</link>.
                 You can find the Yocto Project version of the
                 <filename>bblayers.conf.sample</filename> file in the
-                <filename>meta-poky/conf</filename> directory.
+                <filename>meta-poky/conf/</filename> directory.
             </note>
         </para>
     </section>
 
     <section id='structure-build-conf-sanity_info'>
-        <title><filename>build/conf/sanity_info</filename></title>
+        <title><filename>build/cache/sanity_info</filename></title>
 
         <para>
             This file indicates the state of the sanity checks and is created
@@ -572,8 +569,11 @@
         <title><filename>build/tmp/deploy/images/</filename></title>
 
         <para>
-            This directory receives complete filesystem images.
-            If you want to flash the resulting image from a build onto a device, look here for the image.
+            This directory is populated with the basic output objects of the
+            build (think of them as the "generated artifacts" of the build process),
+            including things like the boot loader image, kernel, root filesystem and more.
+            If you want to flash the resulting image from a build onto a device,
+            look here for the necessary components.
         </para>
 
         <para>
@@ -604,7 +604,7 @@
 
         <para>
             The OpenEmbedded build system creates this directory to hold
-            toolchain installer scripts, which when executed, install the
+            toolchain installer scripts which, when executed, install the
             sysroot that matches your target hardware.
             You can find out more about these installers in the
             "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
@@ -1038,7 +1038,7 @@
         <title><filename>meta/recipes-graphics/</filename></title>
 
         <para>
-            This directory contains X and other graphically related system libraries
+            This directory contains X and other graphically related system libraries.
         </para>
     </section>
 
diff --git a/poky/documentation/ref-manual/ref-system-requirements.xml b/poky/documentation/ref-manual/ref-system-requirements.xml
index 9c2198a76..7d3c71998 100644
--- a/poky/documentation/ref-manual/ref-system-requirements.xml
+++ b/poky/documentation/ref-manual/ref-system-requirements.xml
@@ -8,12 +8,12 @@
     <para>
         Welcome to the Yocto Project Reference Manual!
         This manual provides reference information for the current release
-        of the Yocto Project.
-        The manual is best used after you have an understanding
+        of the Yocto Project, and
+        is most effectively used after you have an understanding
         of the basics of the Yocto Project.
         The manual is neither meant to be read as a starting point to the
-        Yocto Project nor read from start to finish.
-        Use this manual to find variable definitions, class
+        Yocto Project, nor read from start to finish.
+        Rather, use this manual to find variable definitions, class
         descriptions, and so forth as needed during the course of using
         the Yocto Project.
     </para>
@@ -66,12 +66,15 @@
                         below.
                         </para></listitem>
                     <listitem><para>
-                        The Yocto Project is not compatible with the
-                        <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink>
-                        (WSL).
-                        You cannot use a
-                        <link linkend='hardware-build-system-term'>build host</link>
-                        that is running WSL.
+                        You may use Windows Subsystem For Linux v2 to set up a build
+                        host using Windows 10, but validation is not performed
+                        against build hosts using WSLv2.
+                        <note>
+                          The Yocto Project is not compatible with WSLv1, it is
+                          compatible but not officially supported nor validated
+                          with WSLv2, if you still decide to use WSL please upgrade
+                          to WSLv2.
+                        </note>
                         </para></listitem>
                     <listitem><para>
                         If you encounter problems, please go to
@@ -117,7 +120,7 @@
         <para>
             The list of packages you need on the host development system can
             be large when covering all build scenarios using the Yocto Project.
-            This section provides required packages according to
+            This section describes required packages according to
             Linux distribution and function.
         </para>
 
@@ -127,19 +130,29 @@
             <para>
                 The following list shows the required packages by function
                 given a supported Ubuntu or Debian Linux distribution:
-                <note>
-                    If your build system has the
-                    <filename>oss4-dev</filename> package installed, you
-                    might experience QEMU build failures due to the package
-                    installing its own custom
-                    <filename>/usr/include/linux/soundcard.h</filename> on
-                    the Debian system.
-                    If you run into this situation, either of the following
-                    solutions exist:
-                    <literallayout class='monospaced'>
+                <note><title>Notes</title>
+                    <itemizedlist>
+                        <listitem><para>
+                            If your build system has the
+                            <filename>oss4-dev</filename> package installed, you
+                            might experience QEMU build failures due to the package
+                            installing its own custom
+                            <filename>/usr/include/linux/soundcard.h</filename> on
+                            the Debian system.
+                            If you run into this situation, either of the following
+                            solutions exist:
+                            <literallayout class='monospaced'>
      $ sudo apt-get build-dep qemu
      $ sudo apt-get remove oss4-dev
-                    </literallayout>
+                            </literallayout>
+                        </para></listitem>
+                        <listitem><para>
+                            For Debian-8, <filename>python3-git</filename> and <filename>pylint3</filename> are no longer available via <filename>apt-get</filename>.
+                            <literallayout class='monospaced'>
+     $ sudo pip3 install GitPython pylint==1.9.5
+                            </literallayout>
+                        </para></listitem>
+                    </itemizedlist>
                  </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>
@@ -205,18 +218,18 @@
             </para>
         </section>
 
-        <section id='centos-packages'>
-            <title>CentOS Packages</title>
+        <section id='centos-7-packages'>
+            <title>CentOS-7 Packages</title>
 
             <para>
                 The following list shows the required packages by function
-                given a supported CentOS Linux distribution:
+                given a supported CentOS-7 Linux distribution:
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>
                         Packages needed to build an image for a headless
                         system:
                         <literallayout class='monospaced'>
-     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL;
+     $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL;
                         </literallayout>
                         <note><title>Notes</title>
                             <itemizedlist>
@@ -229,29 +242,81 @@
                                     Linux by default.
                                     You need to install these packages
                                     separately.
-                                    </para></listitem>
+                                </para></listitem>
                                 <listitem><para>
                                     The <filename>makecache</filename> command
                                     consumes additional Metadata from
                                     <filename>epel-release</filename>.
-                                    </para></listitem>
+                                </para></listitem>
                             </itemizedlist>
                         </note>
-                        </para></listitem>
+                    </para></listitem>
                     <listitem><para><emphasis>Documentation:</emphasis>
                         Packages needed if you are going to build out the
                         Yocto Project documentation manuals:
                         <literallayout class='monospaced'>
      $ sudo yum install docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto
-                        </literallayout></para></listitem>
+                        </literallayout>
+                    </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='centos-8-packages'>
+            <title>CentOS-8 Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported CentOS-8 Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout>
+                        <note><title>Notes</title>
+                            <itemizedlist>
+                                <listitem><para>
+                                    Extra Packages for Enterprise Linux
+                                    (i.e. <filename>epel-release</filename>)
+                                    is a collection of packages from Fedora
+                                    built on RHEL/CentOS for easy installation
+                                    of packages not included in enterprise
+                                    Linux by default.
+                                    You need to install these packages
+                                    separately.
+                                </para></listitem>
+                                <listitem><para>
+                                    The <filename>PowerTools</filename> repo
+                                    provides additional packages such as
+                                    <filename>rpcgen</filename> and
+                                    <filename>texinfo</filename>.
+                                </para></listitem>
+                                <listitem><para>
+                                    The <filename>makecache</filename> command
+                                    consumes additional Metadata from
+                                    <filename>epel-release</filename>.
+                                </para></listitem>
+                            </itemizedlist>
+                        </note>
+                    </para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo dnf install docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
+                        </literallayout>
+                    </para></listitem>
                 </itemizedlist>
             </para>
         </section>
     </section>
 
-    <section id='required-git-tar-and-python-versions'>
-        <title>Required Git, tar, and Python Versions</title>
+    <section id='required-git-tar-python-and-gcc-versions'>
+        <title>Required Git, tar, Python and gcc Versions</title>
 
         <para>
             In order to use the build system, your host development system
@@ -259,8 +324,8 @@
             Python:
             <itemizedlist>
                 <listitem><para>Git 1.8.3.1 or greater</para></listitem>
-                <listitem><para>tar 1.27 or greater</para></listitem>
-                <listitem><para>Python 3.4.0 or greater</para></listitem>
+                <listitem><para>tar 1.28 or greater</para></listitem>
+                <listitem><para>Python 3.5.0 or greater</para></listitem>
             </itemizedlist>
         </para>
 
@@ -272,6 +337,89 @@
             tarball or use BitBake to build the tarball.
         </para>
 
+        <para>
+            In addition, your host development system must meet the following
+            version requirement for gcc:
+            <itemizedlist>
+                <listitem><para>gcc 5.0 or greater</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            If your host development system does not meet this requirement,
+            you can resolve this by installing a <filename>buildtools-extended</filename>
+            tarball that contains additional tools, the equivalent of <filename>buildtools-essential</filename>.
+        </para>
+        <section id='installing-a-pre-built-buildtools-tarball-with-install-buildtools-script'>
+            <title>Installing a Pre-Built <filename>buildtools</filename> Tarball with <filename>install-buildtools</filename> script</title>
+
+            <para>
+                The <filename>install-buildtools</filename> script is the easiest
+                of the three methods by which you can get these tools. It downloads
+                a pre-built buildtools installer and automatically installs the tools
+                for you:
+            <orderedlist>
+                <listitem><para>
+                    Execute the <filename>install-buildtools</filename> script.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ cd poky
+     $ scripts/install-buildtools --without-extended-buildtools \
+       --base-url &YOCTO_DL_URL;/releases/yocto \
+       --release yocto-&DISTRO; \
+       --installer-version &DISTRO;
+                    </literallayout>
+                    <para>
+                        During execution, the buildtools tarball will be downloaded,
+                        the checksum of the download will be verified, the installer
+                        will be run for you, and some basic checks will be run to
+                        to make sure the installation is functional.
+                    </para>
+                    <para>
+                        To avoid the need of <filename>sudo</filename> privileges,
+                        the <filename>install-buildtools</filename> script will
+                        by default tell the installer to install in:
+                        <literallayout class='monospaced'>
+     <replaceable>/path/to/</replaceable>poky/buildtools
+                        </literallayout>
+                    </para>
+                    <para>
+                        If your host development system needs the additional tools
+                        provided in the <filename>buildtools-extended</filename>
+                        tarball, you can instead execute the
+                        <filename>install-buildtools</filename> script with the
+                        default parameters:
+                        <literallayout class='monospaced'>
+     $ cd poky
+     $ scripts/install-buildtools
+                        </literallayout>
+                    </para>
+                </para></listitem>
+                <listitem><para>
+                    Source the tools environment setup script by using a
+                    command like the following:
+                    <literallayout class='monospaced'>
+     $ source <replaceable>/path/to/</replaceable>poky/buildtools/environment-setup-x86_64-pokysdk-linux
+                    </literallayout>
+                    Of course, you need to supply your installation directory and be
+                    sure to use the right file (i.e. i586 or x86_64).
+                </para>
+                <para>
+                    After you have sourced the setup script,
+                    the tools are added to <filename>PATH</filename>
+                    and any other environment variables required to run the
+                    tools are initialized.
+                    The results are working versions versions of Git, tar,
+                    Python and <filename>chrpath</filename>. And in the case of
+                    the <filename>buildtools-extended</filename> tarball, additional
+                    working versions of tools including <filename>gcc</filename>,
+                    <filename>make</filename> and the other tools included in
+                    <filename>packagegroup-core-buildessential</filename>.
+                </para></listitem>
+            </orderedlist>
+            </para>
+        </section>
+
         <section id='downloading-a-pre-built-buildtools-tarball'>
             <title>Downloading a Pre-Built <filename>buildtools</filename> Tarball</title>
 
@@ -281,14 +429,18 @@
                 <orderedlist>
                     <listitem><para>
                         Locate and download the <filename>*.sh</filename> at
-                        <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
+                        <ulink url='&YOCTO_RELEASE_DL_URL;/buildtools/'></ulink>.
                         </para></listitem>
                     <listitem><para>
                         Execute the installation script.
-                        Here is an example:
+                        Here is an example for the traditional installer:
                         <literallayout class='monospaced'>
      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
                         </literallayout>
+                        Here is an example for the extended installer:
+                        <literallayout class='monospaced'>
+     $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
+                        </literallayout>
                         During execution, a prompt appears that allows you to
                         choose the installation directory.
                         For example, you could choose the following:
@@ -311,7 +463,11 @@
                         and any other environment variables required to run the
                         tools are initialized.
                         The results are working versions versions of Git, tar,
-                        Python and <filename>chrpath</filename>.
+                        Python and <filename>chrpath</filename>. And in the case of
+                        the <filename>buildtools-extended</filename> tarball, additional
+                        working versions of tools including <filename>gcc</filename>,
+                        <filename>make</filename> and the other tools included in
+                        <filename>packagegroup-core-buildessential</filename>.
                         </para></listitem>
                 </orderedlist>
             </para>
@@ -327,7 +483,7 @@
                 <filename>.sh</filename> file and then
                 take steps to transfer and run it on a
                 machine that does not meet the minimal Git, tar, and Python
-                requirements.
+                (or gcc) requirements.
             </para>
 
             <para>
@@ -345,6 +501,10 @@
                         <literallayout class='monospaced'>
      $ bitbake buildtools-tarball
                         </literallayout>
+                        or run the BitBake command to build the extended tarball:
+                        <literallayout class='monospaced'>
+                            $ bitbake buildtools-extended-tarball
+                        </literallayout>
                         <note>
                         The
                         <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>
@@ -358,21 +518,25 @@
                        subdirectory of the
                        <link linkend='build-directory'>Build Directory</link>.
                        The installer file has the string "buildtools"
-                       in the name.
+                       (or "buildtools-extended") in the name.
                        </para></listitem>
                    <listitem><para>
                        Transfer the <filename>.sh</filename> file from the
                        build host to the machine that does not meet the
-                       Git, tar, or Python requirements.
+                       Git, tar, or Python (or gcc) requirements.
                        </para></listitem>
                    <listitem><para>
                        On the machine that does not meet the requirements,
                        run the <filename>.sh</filename> file
                        to install the tools.
-                       Here is an example:
+                       Here is an example for the traditional installer:
                        <literallayout class='monospaced'>
      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
                        </literallayout>
+                       Here is an example for the extended installer:
+                       <literallayout class='monospaced'>
+                           $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
+                       </literallayout>
                        During execution, a prompt appears that allows you to
                        choose the installation directory.
                        For example, you could choose the following:
@@ -384,10 +548,10 @@
                         Source the tools environment setup script by using a
                         command like the following:
                         <literallayout class='monospaced'>
-     $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-i586-poky-linux
+     $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-x86_64-poky-linux
                         </literallayout>
                         Of course, you need to supply your installation directory and be
-                        sure to use the right file (i.e. i585 or x86-64).
+                        sure to use the right file (i.e. i586 or x86_64).
                         </para>
                         <para>
                         After you have sourced the setup script,
@@ -395,7 +559,11 @@
                         and any other environment variables required to run the
                         tools are initialized.
                         The results are working versions versions of Git, tar,
-                        Python and <filename>chrpath</filename>.
+                        Python and <filename>chrpath</filename>. And in the case of
+                        the <filename>buildtools-extended</filename> tarball, additional
+                        working versions of tools including <filename>gcc</filename>,
+                        <filename>make</filename> and the other tools included in
+                        <filename>packagegroup-core-buildessential</filename>.
                         </para></listitem>
                 </orderedlist>
             </para>
diff --git a/poky/documentation/ref-manual/ref-terms.xml b/poky/documentation/ref-manual/ref-terms.xml
index f98546826..722fa7ee2 100644
--- a/poky/documentation/ref-manual/ref-terms.xml
+++ b/poky/documentation/ref-manual/ref-terms.xml
@@ -41,11 +41,13 @@
                 That append file would match any
                 <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename>
                 version of the recipe.
-                So, the append file would match the following recipe names:
+                So, the append file would match any of the following recipe names:
                 <literallayout class='monospaced'>
      busybox_1.21.1.bb
      busybox_1.21.2.bb
      busybox_1.21.3.bb
+     busybox_1.21.10.bb
+     busybox_1.21.25.bb
                 </literallayout>
                 <note><title>Important</title>
                     The use of the "<filename>%</filename>" character
@@ -115,7 +117,7 @@
                         in your home directory within the existing
                         directory <filename>mybuilds</filename>:
                         <literallayout class='monospaced'>
-     $cd $HOME
+     $ cd $HOME
      $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
                         </literallayout>
                         </para></listitem>
@@ -141,7 +143,7 @@
                 The system used to build images in a Yocto Project
                 Development environment.
                 The build system is sometimes referred to as the
-                development host.
+                <firstterm>development host</firstterm>.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Classes:</emphasis>
@@ -393,7 +395,7 @@
                 Poky is not a product level distro.
                 Rather, it is a good starting point for customization.
                 <note>
-                    Poky began an open-source
+                    Poky began as an open-source
                     project initially developed by OpenedHand.
                     OpenedHand developed Poky from the existing
                     OpenEmbedded build system to create a commercially
diff --git a/poky/documentation/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml
index 02abc590c..b44fdcb73 100644
--- a/poky/documentation/ref-manual/ref-variables.xml
+++ b/poky/documentation/ref-manual/ref-variables.xml
@@ -367,7 +367,7 @@
 
         <glossentry id='var-ASSUME_SHLIBS'><glossterm>ASSUME_SHLIBS</glossterm>
             <info>
-                ASSUME_SHLIBS[doc] = Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
+                ASSUME_SHLIBS[doc] = "Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
@@ -495,6 +495,30 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-AVAILABLE_LICENSES'><glossterm>AVAILABLE_LICENSES</glossterm>
+            <info>
+                AVAILABLE_LICENSES[doc] = "List of licenses found in the directories specified by COMMON_LICENSE_DIR and LICENSE_PATH."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+
+                    List of licenses found in the directories specified
+                    by <link linkend='var-COMMON_LICENSE_DIR'><filename>COMMON_LICENSE_DIR</filename></link>
+                    and <link linkend='var-LICENSE_PATH'><filename>LICENSE_PATH</filename></link>.
+
+                    <note>
+                        It is assumed that all changes
+                        to <filename>COMMON_LICENSE_DIR</filename>
+                        and <filename>LICENSE_PATH</filename> have been done
+                        before <filename>AVAILABLE_LICENSES</filename> is
+                        defined
+                        (in <link linkend='ref-classes-license'>license.bbclass</link>).
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-AVAILTUNES'><glossterm>AVAILTUNES</glossterm>
             <info>
                 AVAILTUNES[doc] = "The list of defined CPU and Application Binary Interface (ABI) tunings (i.e.  "tunes") available for use by the OpenEmbedded build system."
@@ -1423,7 +1447,7 @@
                     Use the following format to export the variable to the
                     BitBake environment:
                     <literallayout class='monospaced'>
-     export BBSERVER=localhost:$port"
+     export BBSERVER=localhost:$port
                     </literallayout>
                 </para>
 
@@ -3786,7 +3810,7 @@
                     It is not intended to be user-configurable.
                     It is best to just reference the variable to see which distro features are
                     being backfilled for all distro configurations.
-                    See the <link linkend='ref-features-backfill'>Feature Backfilling</link> section for
+                    See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
                     more information.
                 </para>
             </glossdef>
@@ -6750,6 +6774,25 @@
                     components that are required to produce a functional system
                     image.
                 </note>
+
+                <note><title>Tips</title>
+                    It is possible to define a list of licenses that are allowed
+                    to be used instead of the licenses that are excluded. To do
+                    this, define a
+                    variable <filename>COMPATIBLE_LICENSES</filename> with the
+                    names of the licences that are allowed. Then
+                    define <filename>INCOMPATIBLE_LICENSE</filename> as:
+                    <literallayout class='monospaced'>
+     INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}"
+                    </literallayout>
+                    This will result
+                    in <filename>INCOMPATIBLE_LICENSE</filename> containing the
+                    names of all licences
+                    from <link linkend='var-AVAILABLE_LICENSES'><filename>AVAILABLE_LICENSES</filename></link>
+                    except the ones specified
+                    in <filename>COMPATIBLE_LICENSES</filename>, thus only
+                    allowing the latter licences to be used.
+                </note>
             </glossdef>
         </glossentry>
 
@@ -7428,7 +7471,6 @@
      KBRANCH_genericx86-64  = "standard/base"
      KBRANCH_edgerouter = "standard/edgerouter"
      KBRANCH_beaglebone = "standard/beaglebone"
-     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
                     </literallayout>
                         The <filename>KBRANCH</filename> statements identify
                         the kernel branch to use when building for each
@@ -8746,7 +8788,6 @@
      MACHINE ?= "genericx86"
      MACHINE ?= "genericx86-64"
      MACHINE ?= "beaglebone"
-     MACHINE ?= "mpc8315e-rdb"
      MACHINE ?= "edgerouter"
                     </literallayout>
                     The last five are Yocto Project reference hardware boards, which
@@ -10376,12 +10417,20 @@
                     <filename>PACKAGECONFIG</filename> blocks are defined
                     in recipes when you specify features and then arguments
                     that define feature behaviors.
-                    Here is the basic block structure:
+                    Here is the basic block structure (broken over multiple
+                    lines for readability):
                     <literallayout class='monospaced'>
      PACKAGECONFIG ??= "f1 f2 f3 ..."
-     PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
-     PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
-     PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"
+     PACKAGECONFIG[f1] = "\
+                          --with-f1, \
+                          --without-f1, \
+                          build-deps-for-f1, \
+                          runtime-deps-for-f1, \
+                          runtime-recommends-for-f1, \
+                          packageconfig-conflicts-for-f1 \
+                          "
+     PACKAGECONFIG[f2] = "\
+                         ... and so on and so on ...
                     </literallayout>
                 </para>
 
@@ -10390,7 +10439,7 @@
                     variable itself specifies a space-separated list of the
                     features to enable.
                     Following the features, you can determine the behavior of
-                    each feature by providing up to five order-dependent
+                    each feature by providing up to six order-dependent
                     arguments, which are separated by commas.
                     You can omit any argument you like but must retain the
                     separating commas.
@@ -10420,6 +10469,10 @@
                             (<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
                             that should be added if the feature is enabled.
                             </para></listitem>
+                        <listitem><para>Any conflicting (that is, mutually
+                            exclusive) <filename>PACKAGECONFIG</filename>
+                            settings for this feature.
+                            </para></listitem>
                     </orderedlist>
                 </para>
 
@@ -10427,25 +10480,23 @@
                     Consider the following
                     <filename>PACKAGECONFIG</filename> block taken from the
                     <filename>librsvg</filename> recipe.
-                    In this example the feature is <filename>croco</filename>,
+                    In this example the feature is <filename>gtk</filename>,
                     which has three arguments that determine the feature's
                     behavior.
                     <literallayout class='monospaced'>
-     PACKAGECONFIG ??= "croco"
-     PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
+     PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3"
                     </literallayout>
-                    The <filename>--with-croco</filename> and
-                    <filename>libcroco</filename> arguments apply only if
+                    The <filename>--with-gtk3</filename> and
+                    <filename>gtk+3</filename> arguments apply only if
                     the feature is enabled.
-                    In this case, <filename>--with-croco</filename> is
+                    In this case, <filename>--with-gtk3</filename> is
                     added to the configure script argument list and
-                    <filename>libcroco</filename> is added to
+                    <filename>gtk+3</filename> is added to
                     <filename>DEPENDS</filename>.
                     On the other hand, if the feature is disabled say through
                     a <filename>.bbappend</filename> file in another layer, then
-                    the second argument <filename>--without-croco</filename> is
-                    added to the configure script rather than
-                    <filename>--with-croco</filename>.
+                    the second argument <filename>--without-gtk3</filename> is
+                    added to the configure script instead.
                 </para>
 
                 <para>
@@ -11054,7 +11105,7 @@
 
         <glossentry id='var-PN'><glossterm>PN</glossterm>
             <info>
-                PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package.
+                PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
@@ -11501,23 +11552,35 @@
                     By default, a recipe's own
                     <filename><link linkend='var-PN'>PN</link></filename>
                     is implicitly already in its <filename>PROVIDES</filename>
-                    list.
+                    list and therefore does not need to mention that it provides itself.
                     If a recipe uses <filename>PROVIDES</filename>, the
                     additional aliases are synonyms for the recipe and can
-                    be useful satisfying dependencies of other recipes during
+                    be useful for satisfying dependencies of other recipes during
                     the build as specified by
                     <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
                 </para>
 
                 <para>
                     Consider the following example
-                    <filename>PROVIDES</filename> statement from a recipe
-                    file <filename>libav_0.8.11.bb</filename>:
+                    <filename>PROVIDES</filename> statement from the recipe
+                    file <filename>eudev_3.2.9.bb</filename>:
                     <literallayout class='monospaced'>
-     PROVIDES += "libpostproc"
+     PROVIDES = "udev"
                     </literallayout>
                     The <filename>PROVIDES</filename> statement results in
-                    the "libav" recipe also being known as "libpostproc".
+                    the "eudev" recipe also being available as simply "udev".
+
+                    <note>
+                        Given that a recipe's own recipe name is already
+                        implicitly in its own <filename>PROVIDES</filename> list,
+                        it is unnecessary to add aliases with the "+=" operator;
+                        using a simple assignment will be sufficient. In other
+                        words, while you could write:
+                        <literallayout class='monospaced'>
+     PROVIDES += "udev"
+                        </literallayout>
+                        in the above, the "+=" is overkill and unnecessary.
+                    </note>
                 </para>
 
                 <para>
@@ -13383,8 +13446,7 @@
 
         <glossentry id='var-SKIP_FILEDEPS'><glossterm>SKIP_FILEDEPS</glossterm>
             <info>
-                SKIP_FILEDEPS[doc] = "Enables you to remove all files from
-                the "Provides" section of an RPM package."
+                SKIP_FILEDEPS[doc] = "Enables you to remove all files from the 'Provides' section of an RPM package."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
@@ -15331,7 +15393,7 @@
 
         <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
             <info>
-                TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib."
+                TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or 'newlib'."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
@@ -15646,9 +15708,9 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the target controller to use when running tests
                     against a test image.
-                    The default controller to use is "QemuTarget":
+                    The default controller to use is "qemu":
                     <literallayout class='monospaced'>
-     TEST_TARGET = "QemuTarget"
+     TEST_TARGET = "qemu"
                     </literallayout>
                 </para>
 
@@ -15667,21 +15729,21 @@
                     You can provide the following arguments with
                     <filename>TEST_TARGET</filename>:
                     <itemizedlist>
-                        <listitem><para><emphasis>"QemuTarget":</emphasis>
+                        <listitem><para><emphasis>"qemu":</emphasis>
                             Boots a QEMU image and runs the tests.
                             See the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>"
                             section in the Yocto Project Development Tasks
                             Manual for more information.
                             </para></listitem>
-                        <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
+                        <listitem><para><emphasis>"simpleremote":</emphasis>
                             Runs the tests on target hardware that is already
                             up and running.
                             The hardware can be on the network or it can be
                             a device running an image on QEMU.
                             You must also set
                             <link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link>
-                            when you use "SimpleRemoteTarget".
+                            when you use "simpleremote".
                             <note>
                                 This argument is defined in
                                 <filename>meta/lib/oeqa/controllers/simpleremote.py</filename>.
@@ -16473,7 +16535,7 @@
                     Appends a string to the name of the local version of the
                     U-Boot image.
                     For example, assuming the version of the U-Boot image
-                    built was "2013.10, the full version string reported by
+                    built was "2013.10", the full version string reported by
                     U-Boot would be "2013.10-yocto" given the following
                     statement:
                     <literallayout class='monospaced'>
@@ -16771,18 +16833,21 @@
 
         <glossentry id='var-USERADD_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm>
             <info>
-               USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in files/passwd and files/group files. If set to 'warn', a warning will be issued instead."
+               USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in any of the files listed in USERADD_UID_TABLES and USERADD_GID_TABLES. If set to 'warn', a warning will be issued instead."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    If set to "error", forces the OpenEmbedded build system to
-                    produce an error if the user identification
-                    (<filename>uid</filename>) and group identification
-                    (<filename>gid</filename>) values are not defined
-                    in <filename>files/passwd</filename>
-                    and <filename>files/group</filename> files.
-                    If set to "warn", a warning will be issued instead.
+
+                    If set to <filename>error</filename>, forces the
+                    OpenEmbedded build system to produce an error if the user
+                    identification (<filename>uid</filename>) and group
+                    identification (<filename>gid</filename>) values are not
+                    defined in any of the files listed
+                    in <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>
+                    and <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>. If
+                    set to <filename>warn</filename>, a warning will be issued
+                    instead.
                 </para>
 
                 <para>
@@ -16809,6 +16874,20 @@
                     <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
                     variables.
                 </para>
+
+                <note>
+                    There is a difference in behavior between
+                    setting <filename>USERADD_ERROR_DYNAMIC</filename>
+                    to <filename>error</filename> and setting it
+                    to <filename>warn</filename>. When it is set
+                    to <filename>warn</filename>, the build system will report a
+                    warning for every undefined <filename>uid</filename> and
+                    <filename>gid</filename> in any recipe. But when it is set
+                    to <filename>error</filename>, it will only report errors
+                    for recipes that are actually built. This saves you from
+                    having to add static IDs for recipes that you know will
+                    never be built.
+                </note>
             </glossdef>
         </glossentry>
 
@@ -17108,7 +17187,7 @@
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
                     section in the Yocto Project Development Tasks Manual.
                     For details on the kickstart file format, see the
-                    "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
+                    "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>"
                     Chapter.
                 </para>
             </glossdef>
@@ -17178,8 +17257,7 @@
 
         <glossentry id='var-XSERVER'><glossterm>XSERVER</glossterm>
             <info>
-               XSERVER[doc] = "Specifies the packages that should be installed
-               to provide an X server and drivers for the current machine."
+               XSERVER[doc] = "Specifies the packages that should be installed to provide an X server and drivers for the current machine."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml
index 765c0f218..86b6d7dd0 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml
+++ b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml
@@ -297,8 +297,7 @@
 
          <replaceable>arch</replaceable> is a string representing the target architecture:
                    beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb,
-                   genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb,
-                   mpc8315e-rdb, mpc8315e-rdb-lsb, and qemu*.
+                   genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb and qemu*.
 
 <!-->
          <replaceable>date_time</replaceable> is a date and time stamp.
diff --git a/poky/documentation/sdk-manual/sdk-manual.xml b/poky/documentation/sdk-manual/sdk-manual.xml
index 8d5f6ec4d..537663dad 100644..100755
--- a/poky/documentation/sdk-manual/sdk-manual.xml
+++ b/poky/documentation/sdk-manual/sdk-manual.xml
@@ -22,11 +22,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
@@ -34,7 +33,7 @@
             <revision>
                 <revnumber>2.1</revnumber>
                 <date>April 2016</date>
-                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+                <revremark>The initial document released with the Yocto Project 2.1 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>2.2</revnumber>
@@ -68,9 +67,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>
@@ -92,7 +96,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -109,18 +113,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>
diff --git a/poky/documentation/toaster-manual/toaster-manual.xml b/poky/documentation/toaster-manual/toaster-manual.xml
index d7b4bcee6..e6d424523 100644..100755
--- a/poky/documentation/toaster-manual/toaster-manual.xml
+++ b/poky/documentation/toaster-manual/toaster-manual.xml
@@ -22,11 +22,10 @@
 
         <authorgroup>
             <author>
-                <firstname>Kristi</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>kristi@buzzcollectivemarketing.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
@@ -34,7 +33,7 @@
             <revision>
                 <revnumber>1.8</revnumber>
                 <date>April 2015</date>
-                <revremark>Released with the Yocto Project 1.8 Release.</revremark>
+                <revremark>The initial document released with the Yocto Project 1.8 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>2.0</revnumber>
@@ -78,9 +77,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>
@@ -102,7 +106,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -119,18 +123,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
 
diff --git a/poky/documentation/tools/mega-manual.sed b/poky/documentation/tools/mega-manual.sed
index 374d8e7b0..b1ea9edb7 100644
--- a/poky/documentation/tools/mega-manual.sed
+++ b/poky/documentation/tools/mega-manual.sed
@@ -1,36 +1,36 @@
 # Processes bitbake-user-manual (<word>-<word>-<word> style).
 # This style is for manual three-word folders, which currently is only the BitBake User Manual.
 # We used to have the "yocto-project-qs" and "poky-ref-manual" folders but no longer do.
-# s@"ulink" href="http://www.yoctoproject.org/docs/3.0/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/bitbake-user-manual/bitbake-user-manual.html#@"link" href="#@g
+# s@"ulink" href="http://www.yoctoproject.org/docs/3.1/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#@"link" href="#@g
 
 # Processes all other manuals (<word>-<word> style).
 # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
 # Here is the one-liner:
-# s@"ulink" href="http://www.yoctoproject.org/docs/3.0/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g
+# s@"ulink" href="http://www.yoctoproject.org/docs/3.1/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g
 
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/sdk-manual/sdk-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/bsp-guide/bsp-guide.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/overview-manual/overview-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/kernel-dev/kernel-dev.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/profile-manual/profile-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/3.0/toaster-manual/toaster-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/bsp-guide/bsp-guide.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/overview-manual/overview-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/kernel-dev/kernel-dev.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/profile-manual/profile-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/3.1/toaster-manual/toaster-manual.html#@"link" href="#@g
 
 # Process cases where just an external manual is referenced without an id anchor
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/brief-yoctoprojectqs/brief-yoctoprojectqs.html" target="_top">Yocto Project Quick Build</a>@Yocto Project Quick Build@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/bitbake-user-manual/bitbake-user-manual.html" target="_top">BitBake User Manual</a>@BitBake User Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>@Yocto Project Development Tasks Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/overview-manual/overview-manual.html" target="_top">Yocto Project Overview and Concepts Manual</a>@Yocto project Overview and Concepts Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>@Yocto Project Board Support Package (BSP) Developer's Guide@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/profile-manual/profile-manual.html" target="_top">Yocto Project Profiling and Tracing Manual</a>@Yocto Project Profiling and Tracing Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/kernel-dev/kernel-dev.html" target="_top">Yocto Project Linux Kernel Development Manual</a>@Yocto Project Linux Kernel Development Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>@Yocto Project Reference Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/toaster-manual/toaster-manual.html" target="_top">Toaster User Manual</a>@Toaster User Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html" target="_top">Yocto Project Quick Build</a>@Yocto Project Quick Build@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html" target="_top">BitBake User Manual</a>@BitBake User Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>@Yocto Project Development Tasks Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/overview-manual/overview-manual.html" target="_top">Yocto Project Overview and Concepts Manual</a>@Yocto project Overview and Concepts Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>@Yocto Project Board Support Package (BSP) Developer's Guide@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/profile-manual/profile-manual.html" target="_top">Yocto Project Profiling and Tracing Manual</a>@Yocto Project Profiling and Tracing Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/kernel-dev/kernel-dev.html" target="_top">Yocto Project Linux Kernel Development Manual</a>@Yocto Project Linux Kernel Development Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>@Yocto Project Reference Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/toaster-manual/toaster-manual.html" target="_top">Toaster User Manual</a>@Toaster User Manual@g
 
 # Process a single, rouge occurrence of a linked reference to the Mega-Manual.
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.0/mega-manual/mega-manual.html" target="_top">Yocto Project Mega-Manual</a>@Yocto Project Mega-Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html" target="_top">Yocto Project Mega-Manual</a>@Yocto Project Mega-Manual@g