diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile
index accf234..525a730 100644
--- a/poky/documentation/Makefile
+++ b/poky/documentation/Makefile
@@ -156,7 +156,7 @@
 TARFILES = dev-style.css dev-manual.html figures/buildhistory-web.png \
            figures/dev-title.png figures/buildhistory.png \
            figures/recipe-workflow.png figures/bitbake-build-flow.png \
-           figures/multiconfig_files.png
+           figures/multiconfig_files.png figures/cute-files-npm-example.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -260,7 +260,7 @@
 	figures/sdk-devtool-modify-flow.png \
 	figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \
 	figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \
-	figures/bb_multiconfig_files.png figures/bitbake-title.png
+	figures/bb_multiconfig_files.png figures/bitbake-title.png figures/cute-files-npm-example.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
index 8ddcd5b..9231d14 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -4197,11 +4197,27 @@
             built by layer recipes.
             It is recommended to keep recipes up-to-date with upstream
             version releases.
+        </para>
+
+        <para>
+            While several methods exist that allow you upgrade a recipe,
+            you might consider checking on the upgrade status of a recipe
+            first.
+            You can do so using the
+            <filename>devtool check-upgrade-status</filename> command.
+            See the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</ulink>"
+            section in the Yocto Project Reference Manual for more information.
+        </para>
+
+        <para>
+            The remainder of this section describes three ways you can
+            upgrade a recipe.
             You can use the Automated Upgrade Helper (AUH) to set up
             automatic version upgrades.
             Alternatively, you can use <filename>devtool upgrade</filename>
             to set up semi-automatic version upgrades.
-            Finally, you can even manually upgrade a recipe by editing the
+            Finally, you can manually upgrade a recipe by editing the
             recipe itself.
         </para>
 
@@ -4320,12 +4336,6 @@
                         Make these following configurations:
                         <itemizedlist>
                             <listitem><para>
-                                Enable "distrodata" as follows:
-                                <literallayout class='monospaced'>
-     INHERIT =+ "distrodata"
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>
                                 If you want to enable
                                 <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Build History</ulink>,
                                 which is optional, you need the following
@@ -8964,11 +8974,17 @@
                     <link linkend='handling-optional-module-packaging'>Handling optional module packaging</link>
                     </para></listitem>
                 <listitem><para>
-                    <link linkend='using-runtime-package-management'>Using Runtime Package Management</link>
+                    <link linkend='using-runtime-package-management'>Using runtime package management</link>
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='generating-and-using-signed-packages'>Generating and using signed packages</link>
                     </para></listitem>
                 <listitem><para>
                     <link linkend='testing-packages-with-ptest'>Setting up and running package test (ptest)</link>
                     </para></listitem>
+                <listitem><para>
+                    <link linkend='creating-node-package-manager-npm-packages'>Creating node package manager (NPM) packages</link>
+                    </para></listitem>
             </itemizedlist>
         </para>
 
@@ -10397,6 +10413,292 @@
                 </para>
             </section>
         </section>
+
+        <section id='creating-node-package-manager-npm-packages'>
+            <title>Creating Node Package Manager (NPM) Packages</title>
+
+            <para>
+                <ulink url='https://en.wikipedia.org/wiki/Npm_(software)'>NPM</ulink>
+                is a package manager for the JavaScript programming
+                language.
+                The Yocto Project supports the NPM
+                <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink>.
+                You can use this fetcher in combination with
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename></ulink>
+                to create recipes that produce NPM packages.
+            </para>
+
+            <para>
+                Two workflows exist that allow you to create NPM packages
+                using <filename>devtool</filename>: the NPM registry modules
+                method and the NPM project code method.
+                <note>
+                    While it is possible to create NPM recipes manually,
+                    using <filename>devtool</filename> is far simpler.
+                </note>
+                Additionally, some requirements and caveats exist.
+            </para>
+
+            <section id='npm-package-creation-requirements'>
+                <title>Requirements and Caveats</title>
+
+                <para>
+                    You need to be aware of the following before using
+                    <filename>devtool</filename> to create NPM packages:
+                    <itemizedlist>
+                        <listitem><para>
+                            Of the two methods that you can use
+                            <filename>devtool</filename> to create NPM
+                            packages, the registry approach is slightly
+                            simpler.
+                            However, you might consider the project
+                            approach because you do not have to publish
+                            your module in the NPM registry
+                            (<ulink url='https://docs.npmjs.com/misc/registry'><filename>npm-registry</filename></ulink>),
+                            which is NPM's public registry.
+                            </para></listitem>
+                        <listitem><para>
+                            Be familiar with
+                            <ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename></ulink>.
+                            </para></listitem>
+                        <listitem><para>
+                            The NPM host tools need the native
+                            <filename>nodejs-npm</filename> package, which
+                            is part of the OpenEmbedded environment.
+                            You need to get the package by cloning the
+                            <ulink url='https://github.com/openembedded/meta-openembedded'></ulink>
+                            repository out of GitHub.
+                            Be sure to add the path to your local copy to
+                            your <filename>bblayers.conf</filename> file.
+                            </para></listitem>
+                        <listitem><para>
+                            <filename>devtool</filename> cannot detect
+                            native libraries in module dependencies.
+                            Consequently, you must manually add packages
+                            to your recipe.
+                            </para></listitem>
+                        <listitem><para>
+                            While deploying NPM packages,
+                            <filename>devtool</filename> cannot determine
+                            which dependent packages are missing on the
+                            target (e.g. the node runtime
+                            <filename>nodejs</filename>).
+                            Consequently, you need to find out what
+                            files are missing and be sure they are on the
+                            target.
+                            </para></listitem>
+                        <listitem><para>
+                            Although you might not need NPM to run your
+                            node package, it is useful to have NPM on your
+                            target.
+                            The NPM package name is
+                            <filename>nodejs-npm</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='npm-using-the-registry-modules-method'>
+                <title>Using the Registry Modules Method</title>
+
+                <para>
+                    This section presents an example that uses the
+                    <filename>cute-files</filename> module, which is a
+                    file browser web application.
+                    <note>
+                        You must know the <filename>cute-files</filename>
+                        module version.
+                    </note>
+                </para>
+
+                <para>
+                    The first thing you need to do is use
+                    <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"
+                    </literallayout>
+                    The <filename>devtool add</filename> command runs
+                    <filename>recipetool create</filename> and uses the
+                    same fetch URI to download each dependency and capture
+                    license details where possible.
+                    The result is a generated recipe.
+                </para>
+
+                <para>
+                    The recipe file is fairly simple and contains every
+                    license that <filename>recipetool</filename> finds
+                    and includes the licenses in the recipe's
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink>
+                    variables.
+                    You need to examine the variables and look for those
+                    with "unknown" in the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
+                    field.
+                    You need to track down the license information for
+                    "unknown" modules and manually add the information to the
+                    recipe.
+                </para>
+
+                <para>
+                    <filename>recipetool</filename> creates "shrinkwrap" and
+                    "lockdown" files 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
+                        licenses for all of the dependencies represented
+                        in the license manifest of the image.
+                    </note>
+                </para>
+
+                <para>
+                    The <filename>devtool edit-recipe</filename> command
+                    lets you take a look at the recipe:
+                    <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"
+     LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
+                         file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \
+                         file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \
+                         ...
+
+     SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}"
+     NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
+     NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"
+     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"
+                    </literallayout>
+                    Three key points exist in the previous example:
+                    <itemizedlist>
+                        <listitem><para>
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                            uses the NPM scheme so that the NPM fetcher
+                            is used.
+                            </para></listitem>
+                        <listitem><para>
+                            <filename>recipetool</filename> collects all
+                            the license information.
+                            If a sub-module's license is unavailable,
+                            the sub-module's name appears in the comments.
+                            </para></listitem>
+                        <listitem><para>
+                            The <filename>inherit npm</filename> statement
+                            causes the
+                            <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-npm'><filename>npm</filename></ulink>
+                            class to package up all the modules.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    You can run the following command to build the
+                    <filename>cute-files</filename> package:
+                    <literallayout class='monospaced'>
+     $ devtool build cute-files
+                    </literallayout>
+                    Remember that <filename>nodejs</filename> must be
+                    installed on the target before your package.
+                </para>
+
+                <para>
+                    Assuming 192.168.7.2 for the target's IP address, use
+                    the following command to deploy your package:
+                    <literallayout class='monospaced'>
+     $ devtool deploy-target -s cute-files root@192.168.7.2
+                    </literallayout>
+                    Once the package is installed on the target, you can
+                    test the application:
+                    <note>
+                        Because of a know issue, you cannot simply run
+                        <filename>cute-files</filename> as you would if you
+                        had run <filename>npm install</filename>.
+                    </note>
+                    <literallayout class='monospaced'>
+     $ cd /usr/lib/node_modules/cute-files
+     $ node cute-files.js
+                    </literallayout>
+                    On a browser, go to
+                    <filename>http://192.168.7.2:3000</filename> and you
+                    see the following:
+                    <imagedata fileref="figures/cute-files-npm-example.png" align="center" width="6in" depth="4in" />
+                </para>
+
+                <para>
+                    You can find the recipe in
+                    <filename>workspace/recipes/cute-files</filename>.
+                    You can use the recipe in any layer you choose.
+                </para>
+            </section>
+
+            <section id='npm-using-the-npm-projects-method'>
+                <title>Using the NPM Projects Code Method</title>
+
+                <para>
+                    Although it is useful to package modules already in the
+                    NPM registry, adding <filename>node.js</filename> projects
+                    under development is a more common developer use case.
+                </para>
+
+                <para>
+                    This section covers the NPM projects code method, which is
+                    very similar to the "registry" approach described in the
+                    previous section.
+                    In the NPM projects method, you provide
+                    <filename>devtool</filename> with an URL that points to the
+                    source files.
+                </para>
+
+                <para>
+                    Replicating the same example, (i.e.
+                    <filename>cute-files</filename>) use the following command:
+                    <literallayout class='monospaced'>
+     $ devtool add https://github.com/martinaglv/cute-files.git
+                    </literallayout>
+                    The recipe this command generates is very similar to the
+                    recipe created in the previous section.
+                    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 \
+               "
+                    </literallayout>
+                    In this example, the main module is taken from the Git
+                    repository and dependents are taken from the NPM registry.
+                    Other than those differences, the recipe is basically the
+                    same between the two methods.
+                    You can build and deploy the package exactly as described
+                    in the previous section that uses the registry modules
+                    method.
+                </para>
+            </section>
+        </section>
     </section>
 
     <section id='efficiently-fetching-source-files-during-a-build'>
@@ -10519,7 +10821,7 @@
             <title>Using systemd Exclusively</title>
 
             <para>
-                Set the these variables in your distribution configuration
+                Set these variables in your distribution configuration
                 file as follows:
                 <literallayout class='monospaced'>
      DISTRO_FEATURES_append = " systemd"
diff --git a/poky/documentation/dev-manual/figures/cute-files-npm-example.png b/poky/documentation/dev-manual/figures/cute-files-npm-example.png
new file mode 100644
index 0000000..1ebe74f
--- /dev/null
+++ b/poky/documentation/dev-manual/figures/cute-files-npm-example.png
Binary files differ
diff --git a/poky/documentation/mega-manual/figures/cute-files-npm-example.png b/poky/documentation/mega-manual/figures/cute-files-npm-example.png
new file mode 100644
index 0000000..1ebe74f
--- /dev/null
+++ b/poky/documentation/mega-manual/figures/cute-files-npm-example.png
Binary files differ
diff --git a/poky/documentation/overview-manual/overview-manual-concepts.xml b/poky/documentation/overview-manual/overview-manual-concepts.xml
index 8a1b38c..f085dd7 100644
--- a/poky/documentation/overview-manual/overview-manual-concepts.xml
+++ b/poky/documentation/overview-manual/overview-manual-concepts.xml
@@ -924,17 +924,18 @@
                 <title>Source Control Managers (Optional)</title>
 
                 <para>
-                    Another place the build system can get source files from is
-                    through a Source Control Manager (SCM) such as Git or
-                    Subversion.
+                    Another place from which the build system can get source
+                    files is with
+                    <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink>
+                    employing various Source Control Managers (SCMs) such as
+                    Git or Subversion.
                     In such cases, a repository is cloned or checked out.
                     The
                     <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>
                     task inside BitBake uses
                     the <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                     variable and the argument's prefix to determine the correct
-                    <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'><filename>fetcher</filename></ulink>
-                    module.
+                    fetcher module.
                     <note>
                         For information on how to have the OpenEmbedded build
                         system generate tarballs for Git repositories and place
diff --git a/poky/documentation/ref-manual/migration.xml b/poky/documentation/ref-manual/migration.xml
index 1ecf5b9..ade8787 100644
--- a/poky/documentation/ref-manual/migration.xml
+++ b/poky/documentation/ref-manual/migration.xml
@@ -2566,9 +2566,7 @@
             <link linkend='oe-core'>OE-Core</link>.
             The change includes <filename>package_regex.inc</filename> and
             <filename>distro_alias.inc</filename>, which are typically enabled
-            when using the
-            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
-            class.
+            when using the <filename>distrodata</filename> class.
             Additionally, the contents of
             <filename>upstream_tracking.inc</filename> has now been split out
             to the relevant recipes.
diff --git a/poky/documentation/ref-manual/ref-classes.xml b/poky/documentation/ref-manual/ref-classes.xml
index d602851..ece47e7 100644
--- a/poky/documentation/ref-manual/ref-classes.xml
+++ b/poky/documentation/ref-manual/ref-classes.xml
@@ -335,18 +335,6 @@
     </para>
 </section>
 
-<section id='ref-classes-bugzilla'>
-    <title><filename>bugzilla.bbclass</filename></title>
-
-    <para>
-        The <filename>bugzilla</filename> class supports setting up an
-        instance of Bugzilla in which you can automatically files bug reports
-        in response to build failures.
-        For this class to work, you need to enable the XML-RPC interface in
-        the instance of Bugzilla.
-    </para>
-</section>
-
 <section id='ref-classes-buildhistory'>
     <title><filename>buildhistory.bbclass</filename></title>
 
@@ -714,39 +702,6 @@
     </para>
 </section>
 
-<section id='ref-classes-distrodata'>
-    <title><filename>distrodata.bbclass</filename></title>
-
-    <para>
-        The <filename>distrodata</filename> class
-        provides for automatic checking for upstream recipe updates.
-        The class creates a comma-separated value (CSV) spreadsheet that
-        contains information about the recipes.
-        The information provides the
-        <link linkend='ref-tasks-distrodata'><filename>do_distrodata</filename></link>
-        and
-        <filename>do_distro_check</filename> tasks, which do upstream checking
-        and also verify if a package is used in multiple major distributions.
-    </para>
-
-    <para>
-        The class is not included by default.
-        To use it, you must set the
-        <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
-        variable:
-        <literallayout class='monospaced'>
-     INHERIT+= "distrodata"
-        </literallayout>
-    </para>
-
-    <para>
-        The <filename>distrodata</filename> class also provides the
-        <link linkend='ref-tasks-checkpkg'><filename>do_checkpkg</filename></link>
-        task, which can be used against a simple recipe or against an
-        image to get all its recipe information.
-    </para>
-</section>
-
 <section id='ref-classes-distutils'>
     <title><filename>distutils*.bbclass</filename></title>
 
@@ -776,11 +731,6 @@
         some of the <filename>distutils*</filename> classes to provide common
         Python2 support.
     </para>
-
-    <para>
-	    The <filename>distutils-tools</filename> class supports recipes for
-        additional "distutils" tools.
-    </para>
 </section>
 
 <section id='ref-classes-distutils3'>
@@ -2335,13 +2285,16 @@
     <title><filename>npm.bbclass</filename></title>
 
     <para>
-        Provides support for building Node.js software fetched using the npm
-        package manager.
+        Provides support for building Node.js software fetched using the
+        <ulink url='https://en.wikipedia.org/wiki/Npm_(software)'>node package manager (NPM)</ulink>.
         <note>
             Currently, recipes inheriting this class must use the
             <filename>npm://</filename> fetcher to have dependencies fetched
             and packaged automatically.
         </note>
+        For information on how to create NPM packages, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-node-package-manager-npm-packages'>Creating Node Package Manager (NPM) Packages</ulink>"
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
diff --git a/poky/documentation/ref-manual/ref-devtool-reference.xml b/poky/documentation/ref-manual/ref-devtool-reference.xml
index b974d0f..4810d28 100644
--- a/poky/documentation/ref-manual/ref-devtool-reference.xml
+++ b/poky/documentation/ref-manual/ref-devtool-reference.xml
@@ -34,7 +34,7 @@
             You can run <filename>devtool --help</filename> to see all
             the commands:
             <literallayout class='monospaced'>
-     $ devtool --help
+     $ devtool -h
      NOTE: Starting bitbake server...
      usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
                     [--color COLOR] [-h]
@@ -43,50 +43,48 @@
      OpenEmbedded development tool
 
      options:
-       --basepath BASEPATH  Base directory of SDK / build directory
-       --bbpath BBPATH      Explicitly specify the BBPATH, rather than getting it
-                            from the metadata
-       -d, --debug          Enable debug output
-       -q, --quiet          Print only errors
-       --color COLOR        Colorize output (where COLOR is auto, always, never)
-       -h, --help           show this help message and exit
+       --basepath BASEPATH   Base directory of SDK / build directory
+       --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it
+                             from the metadata
+       -d, --debug           Enable debug output
+       -q, --quiet           Print only errors
+       --color COLOR         Colorize output (where COLOR is auto, always, never)
+       -h, --help            show this help message and exit
 
      subcommands:
        Beginning work on a recipe:
-         add                  Add a new recipe
-         modify               Modify the source for an existing recipe
-         upgrade              Upgrade an existing recipe
+         add                   Add a new recipe
+         modify                Modify the source for an existing recipe
+         upgrade               Upgrade an existing recipe
        Getting information:
-         status               Show workspace status
-         search               Search available recipes
-         latest-version       Report the latest version of an existing recipe
+         status                Show workspace status
+         search                Search available recipes
+         latest-version        Report the latest version of an existing recipe
+         check-upgrade-status  Report upgradability for multiple (or all) recipes
        Working on a recipe in the workspace:
-         build                Build a recipe
-         rename               Rename a recipe file in the workspace
-         edit-recipe          Edit a recipe file
-         find-recipe          Find a recipe file
-         configure-help       Get help on configure script options
-         update-recipe        Apply changes from external source tree to recipe
-         reset                Remove a recipe from your workspace
-         finish               Finish working on a recipe in your workspace
+         build                 Build a recipe
+         rename                Rename a recipe file in the workspace
+         edit-recipe           Edit a recipe file
+         find-recipe           Find a recipe file
+         configure-help        Get help on configure script options
+         update-recipe         Apply changes from external source tree to recipe
+         reset                 Remove a recipe from your workspace
+         finish                Finish working on a recipe in your workspace
        Testing changes on target:
-         deploy-target        Deploy recipe output files to live target machine
-         undeploy-target      Undeploy recipe output files in live target machine
-         build-image          Build image including workspace recipe packages
+         deploy-target         Deploy recipe output files to live target machine
+         undeploy-target       Undeploy recipe output files in live target machine
+         build-image           Build image including workspace recipe packages
        Advanced:
-         create-workspace     Set up workspace in an alternative location
-         export               Export workspace into a tar archive
-         import               Import exported tar archive into workspace
-         extract              Extract the source for an existing recipe
-         sync                 Synchronize the source tree for an existing recipe
+         create-workspace      Set up workspace in an alternative location
+         export                Export workspace into a tar archive
+         import                Import exported tar archive into workspace
+         extract               Extract the source for an existing recipe
+         sync                  Synchronize the source tree for an existing recipe
      Use devtool &lt;subcommand&gt; --help to get help on a specific command
             </literallayout>
-        </para>
-
-        <para>
-                As directed in the general help output, you can get more
-                syntax on a specific command by providing the command
-                name and using <filename>--help</filename>:
+            As directed in the general help output, you can get more syntax
+            on a specific command by providing the command name and using
+            "--help":
             <literallayout class='monospaced'>
      $ devtool add --help
      NOTE: Starting bitbake server...
@@ -429,6 +427,108 @@
         </para>
     </section>
 
+    <section id='devtool-checking-on-the-upgrade-status-of-a-recipe'>
+        <title>Checking on the Upgrade Status of a Recipe</title>
+
+        <para>
+            Upstream recipes change over time.
+            Consequently, you might find that you need to determine if you
+            can upgrade a recipe to a newer version.
+        </para>
+
+        <para>
+            To check on the upgrade status of a recipe, use the
+            <filename>devtool check-upgrade-status</filename> command.
+            The command displays a table of your current recipe versions,
+            the latest upstream versions, the email address of the recipe's
+            maintainer, and any additional information such as commit hash
+            strings and reasons you might not be able to upgrade a particular
+            recipe.
+            <note><title>NOTES:</title>
+                <itemizedlist>
+                    <listitem><para>
+                        For the <filename>oe-core</filename> layer, recipe
+                        maintainers come from the
+                        <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc'><filename>maintainers.inc</filename></ulink>
+                        file.
+                        </para></listitem>
+                    <listitem><para>
+                        If the recipe is using the
+                        <ulink url='&YOCTO_DOCS_BB_URL;#git-fetcher'>Git fetcher</ulink>
+                        rather than a tarball, the commit hash points to the
+                        commit that matches the recipe's latest version tag.
+                        </para></listitem>
+                </itemizedlist>
+            </note>
+        </para>
+
+        <para>
+            As with all <filename>devtool</filename> commands, you can get
+            help on the individual command:
+            <literallayout class='monospaced'>
+     $ devtool check-upgrade-status -h
+     NOTE: Starting bitbake server...
+     usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]]
+
+     Prints a table of recipes together with versions currently provided by
+     recipes, and latest upstream versions, when there is a later version available
+
+     arguments:
+       recipe      Name of the recipe to report (omit to report upgrade info for
+                   all recipes)
+
+     options:
+      -h, --help  show this help message and exit
+       --all, -a   Show all recipes, not just recipes needing upgrade
+            </literallayout>
+        </para>
+
+        <para>
+            Unless you provide a specific recipe name on the command line,
+            the command checks all recipes in all configured layers.
+        </para>
+
+        <para>
+            Following is a partial example table that reports on all the
+            recipes.
+            Notice the reported reason for not upgrading the
+            <filename>base-passwd</filename> recipe.
+            In this example, while a new version is available upstream,
+            you do not want to use it because the dependency on
+            <filename>cdebconf</filename> is not easily satisfied.
+            <note>
+                When a reason for not upgrading displays, the reason is
+                usually written into the recipe using the
+                <filename>RECIPE_NO_UPDATE_REASON</filename> variable.
+                See the
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb'><filename>base-passwd.bb</filename></ulink>
+                recipe for an example.
+            </note>
+            <literallayout class='monospaced'>
+     $ devtool check-upgrade-status
+         ...
+         NOTE: acpid                     2.0.30          2.0.31
+     Ross Burton &lt;ross.burton@intel.com&gt;
+         NOTE: u-boot-fw-utils           2018.11         2019.01
+     Marek Vasut &lt;marek.vasut@gmail.com&gt;
+     d3689267f92c5956e09cc7d1baa4700141662bff
+         NOTE: u-boot-tools              2018.11         2019.01
+     Marek Vasut &lt;marek.vasut@gmail.com&gt;
+     d3689267f92c5956e09cc7d1baa4700141662bff
+          .
+          .
+          .
+         NOTE: base-passwd               3.5.29          3.5.45
+     Anuj Mittal &lt;anuj.mittal@intel.com&gt;  cannot be updated due to: Version
+     3.5.38 requires cdebconf for update-passwd utility
+         NOTE: busybox                   1.29.2          1.30.0
+     Andrej Valek &lt;andrej.valek@siemens.com&gt;
+         NOTE: dbus-test                 1.12.10         1.12.12
+     Chen Qi &lt;Qi.Chen@windriver.com&gt;
+            </literallayout>
+        </para>
+    </section>
+
     <section id='devtool-upgrading-a-recipe'>
         <title>Upgrading a Recipe</title>
 
@@ -443,6 +543,13 @@
             section of the Yocto Project Development Tasks Manual.
             This section overviews the <filename>devtool upgrade</filename>
             command.
+            <note>
+                Before you upgrade a recipe, you can check on its upgrade
+                status.
+                See the
+                "<link linkend='devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</link>"
+                for more information.
+            </note>
         </para>
 
         <para>
diff --git a/poky/documentation/ref-manual/ref-features.xml b/poky/documentation/ref-manual/ref-features.xml
index 7a3555d..b057d2d 100644
--- a/poky/documentation/ref-manual/ref-features.xml
+++ b/poky/documentation/ref-manual/ref-features.xml
@@ -76,8 +76,6 @@
                     </para></listitem>
                 <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
                     </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support
-                    </para></listitem>
                 <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
                     </para></listitem>
                 <listitem><para><emphasis>pcbios:</emphasis> Support for booting through BIOS
@@ -190,8 +188,6 @@
                     support.</para></listitem>
                 <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
                     </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Include IrDA support.
-                    </para></listitem>
                 <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
                     support (e.g. keymaps will be loaded during boot).
                     </para></listitem>
diff --git a/poky/documentation/ref-manual/ref-tasks.xml b/poky/documentation/ref-manual/ref-tasks.xml
index 8f3ff26..011e0d7 100644
--- a/poky/documentation/ref-manual/ref-tasks.xml
+++ b/poky/documentation/ref-manual/ref-tasks.xml
@@ -158,32 +158,6 @@
         </para>
     </section>
 
-    <section id='ref-tasks-distrodata'>
-        <title><filename>do_distrodata</filename></title>
-
-        <para>
-            Provides information about the recipe.
-        </para>
-
-        <para>
-            The <filename>distrodata</filename> task is included as part of the
-            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
-            class.
-        </para>
-
-        <para>
-            To build the <filename>distrodata</filename> task, use the
-            <filename>bitbake</filename> command with the "-c" option and
-            task name:
-            <literallayout class='monospaced'>
-     $ bitbake core-image-minimal -c distrodata
-            </literallayout>
-            By default, the results are stored in
-            <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link>
-            (e.g. <filename>$BUILD_DIR/tmp/log</filename>).
-        </para>
-    </section>
-
     <section id='ref-tasks-fetch'>
         <title><filename>do_fetch</filename></title>
 
@@ -192,7 +166,8 @@
             This task uses the
             <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
             variable and the argument's prefix to determine the correct
-            fetcher module.
+            <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetcher</ulink>
+            module.
         </para>
     </section>
 
@@ -635,9 +610,18 @@
         </para>
 
         <para>
-            The <filename>checkpkg</filename> task is included as part of the
-            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
-            class.
+            To check the upstream version and status of a recipe, use the
+            following devtool commands:
+            <literallayout class='monospaced'>
+     $ devtool latest-version
+     $ devtool check-upgrade-status
+            </literallayout>
+            See the
+            "<link linkend='ref-devtool-reference'><filename>devtool</filename> Quick Reference</link>"
+            chapter for more information on <filename>devtool</filename>.
+            See the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe'>Checking on the Upgrade Status of a Recipe</ulink>"
+            section for information on checking the upgrade status of a recipe.
         </para>
 
         <para>
diff --git a/poky/documentation/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml
index 0d01c16..12876e3 100644
--- a/poky/documentation/ref-manual/ref-variables.xml
+++ b/poky/documentation/ref-manual/ref-variables.xml
@@ -16629,16 +16629,16 @@
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    When the
-                    <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
-                    class is enabled globally, you can perform a per-recipe
-                    check for what the latest upstream source code version is
-                    by calling
+                    You can perform a per-recipe check for what the latest
+                    upstream source code version is by calling
                     <filename>bitbake -c checkpkg</filename> <replaceable>recipe</replaceable>.
                     If the recipe source code is provided from Git
                     repositories, the OpenEmbedded build system determines the
                     latest upstream version by picking the latest tag from the
                     list of all repository tags.
+                </para>
+
+                <para>
                     You can use the
                     <filename>UPSTREAM_CHECK_GITTAGREGEX</filename>
                     variable to provide a regular expression to filter only the
@@ -16658,11 +16658,8 @@
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    When the
-                    <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
-                    class is enabled globally, use the
-                    <filename>UPSTREAM_CHECK_REGEX</filename> variable to
-                    specify a different regular expression instead of the
+                    Use the <filename>UPSTREAM_CHECK_REGEX</filename> variable
+                    to specify a different regular expression instead of the
                     default one when the package checking system is parsing
                     the page found using
                     <link linkend='var-UPSTREAM_CHECK_URI'><filename>UPSTREAM_CHECK_URI</filename></link>.
@@ -16680,12 +16677,9 @@
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    When the
-                    <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
-                    class is enabled globally, you can perform a per-recipe
-                    check for what the latest upstream source code version is
-                    by calling <filename>bitbake -c checkpkg</filename>
-                    <replaceable>recipe</replaceable>.
+                    You can perform a per-recipe check for what the latest
+                    upstream source code version is by calling
+                    <filename>bitbake -c checkpkg</filename> <replaceable>recipe</replaceable>.
                     If the source code is provided from tarballs, the latest
                     version is determined by fetching the directory listing
                     where the tarball is and attempting to find a later tarball.
diff --git a/poky/documentation/sdk-manual/sdk-extensible.xml b/poky/documentation/sdk-manual/sdk-extensible.xml
index f7c5c00..bd52784 100644
--- a/poky/documentation/sdk-manual/sdk-extensible.xml
+++ b/poky/documentation/sdk-manual/sdk-extensible.xml
@@ -825,7 +825,9 @@
                 versioning schemes, extract code into or out of the
                 <filename>devtool</filename>
                 <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>,
-                and work with any source file forms that the fetchers support.
+                and work with any source file forms that the
+                <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink>
+                support.
             </para>
 
             <para>