diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile
index 33bbca0..9fb6814 100644
--- a/poky/documentation/Makefile
+++ b/poky/documentation/Makefile
@@ -47,9 +47,11 @@
 	@rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js
 
 epub: $(PNGs)
+	$(SOURCEDIR)/set_versions.py
 	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
 latexpdf: $(PDFs)
+	$(SOURCEDIR)/set_versions.py
 	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
 all: html epub latexpdf
diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst
index 12cab1d..7179f25 100644
--- a/poky/documentation/brief-yoctoprojectqs/index.rst
+++ b/poky/documentation/brief-yoctoprojectqs/index.rst
@@ -424,9 +424,9 @@
    development documentation, and access to a rich Yocto Project
    Development Community into which you can tap.
 
--  **Video Seminar:** The `Introduction to the Yocto Project and Bitbake, Part 1
+-  **Video Seminar:** The `Introduction to the Yocto Project and BitBake, Part 1
    <https://youtu.be/yuE7my3KOpo>`__ and
-   `Introduction to the Yocto Project and Bitbake, Part 2
+   `Introduction to the Yocto Project and BitBake, Part 2
    <https://youtu.be/iZ05TTyzGHk>`__ videos offer a video seminar
    introducing you to the most important aspects of developing a
    custom embedded Linux distribution with the Yocto Project.
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 8ec7f29..280b160 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -725,6 +725,7 @@
 
 .. image:: figures/bsp-dev-flow.png
    :align: center
+   :width: 70%
 
 #. *Set up Your Host Development System to Support Development Using the
    Yocto Project*: See the ":ref:`dev-manual/start:preparing the build host`"
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index a7cdf41..baf550e 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -19,7 +19,7 @@
     import yaml
 except ImportError:
     sys.stderr.write("The Yocto Project Sphinx documentation requires PyYAML.\
-    \nPlease make sure to install pyyaml python package.\n")
+    \nPlease make sure to install pyyaml Python package.\n")
     sys.exit(1)
 
 # current_version = "dev"
@@ -108,7 +108,7 @@
     'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None),
 }
 
-# Intersphinx config to use cross reference with Bitbake user manual
+# Intersphinx config to use cross reference with BitBake user manual
 intersphinx_mapping = {
     'bitbake': ('https://docs.yoctoproject.org/bitbake/' + bitbake_version, None)
 }
@@ -129,7 +129,7 @@
     }
 except ImportError:
     sys.stderr.write("The Sphinx sphinx_rtd_theme HTML theme was not found.\
-    \nPlease make sure to install the sphinx_rtd_theme python package.\n")
+    \nPlease make sure to install the sphinx_rtd_theme Python package.\n")
     sys.exit(1)
 
 html_logo = 'sphinx-static/YoctoProject_Logo_RGB.jpg'
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index b228c75..ca6d594 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -1125,6 +1125,7 @@
 
 .. image:: figures/recipe-workflow.png
    :align: center
+   :width: 50%
 
 Locate or Automatically Create a Base Recipe
 --------------------------------------------
@@ -3618,7 +3619,7 @@
 The following figure and list overviews the build process:
 
 .. image:: figures/bitbake-build-flow.png
-   :align: center
+   :width: 100%
 
 1. *Set up Your Host Development System to Support Development Using the
    Yocto Project*: See the ":doc:`start`" section for options on how to get a
@@ -3736,6 +3737,7 @@
 
    .. image:: figures/multiconfig_files.png
       :align: center
+      :width: 50%
 
    The reason for this required file hierarchy is because the :term:`BBPATH`
    variable is not constructed until the layers are parsed.
@@ -4826,7 +4828,7 @@
    require conf/multilib.conf
    MULTILIBS = "multilib:lib32"
    DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
-   IMAGE_INSTALL:append = "lib32-glib-2.0"
+   IMAGE_INSTALL:append = " lib32-glib-2.0"
 
 This example enables an additional library named
 ``lib32`` alongside the normal target packages. When combining these
@@ -5392,7 +5394,7 @@
 
 The ``wic`` command generates partitioned images from existing
 OpenEmbedded build artifacts. Image generation is driven by partitioning
-commands contained in an Openembedded kickstart file (``.wks``)
+commands contained in an OpenEmbedded kickstart file (``.wks``)
 specified either directly on the command line or as one of a selection
 of canned kickstart files as shown with the ``wic list images`` command
 in the
@@ -5464,7 +5466,7 @@
 
 -  You need to have the build artifacts already available, which
    typically means that you must have already created an image using the
-   Openembedded build system (e.g. ``core-image-minimal``). While it
+   OpenEmbedded build system (e.g. ``core-image-minimal``). While it
    might seem redundant to generate an image in order to create an image
    using Wic, the current version of Wic requires the artifacts in the
    form generated by the OpenEmbedded build system.
@@ -5479,7 +5481,9 @@
    variable.
 
 -  Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>`
-   as part of the :term:`WKS_FILE` variable
+   as part of the :term:`WKS_FILE` variable. If multiple candidate files can
+   be provided by different layers, specify all the possible names through the
+   :term:`WKS_FILES` variable instead.
 
 Getting Help
 ------------
@@ -5546,7 +5550,7 @@
 -----------------
 
 You can use Wic in two different modes, depending on how much control
-you need for specifying the Openembedded build artifacts that are used
+you need for specifying the OpenEmbedded build artifacts that are used
 for creating the image: Raw and Cooked:
 
 -  *Raw Mode:* You explicitly specify build artifacts through Wic
@@ -5880,7 +5884,7 @@
 image, and boot from the media. You can write the image by using
 ``bmaptool`` or ``dd``::
 
-   $ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
+   $ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
 
 or ::
 
@@ -6432,10 +6436,10 @@
 new build directory.
 
 The OpenEmbedded build system uses the environment variable
-``TEMPLATECONF`` to locate the directory from which it gathers
+:term:`TEMPLATECONF` to locate the directory from which it gathers
 configuration information that ultimately ends up in the
 :term:`Build Directory` ``conf`` directory.
-By default, ``TEMPLATECONF`` is set as follows in the ``poky``
+By default, :term:`TEMPLATECONF` is set as follows in the ``poky``
 repository::
 
    TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
@@ -6450,7 +6454,7 @@
 
 To override these default configuration files with configurations you
 want used within every new Build Directory, simply set the
-``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF``
+:term:`TEMPLATECONF` variable to your directory. The :term:`TEMPLATECONF`
 variable is set in the ``.templateconf`` file, which is in the top-level
 :term:`Source Directory` folder
 (e.g. ``poky``). Edit the ``.templateconf`` so that it can locate your
@@ -6490,7 +6494,7 @@
 
 Changing the listed common targets is as easy as editing your version of
 ``conf-notes.txt`` in your custom template configuration directory and
-making sure you have ``TEMPLATECONF`` set to your directory.
+making sure you have :term:`TEMPLATECONF` set to your directory.
 
 Conserving Disk Space
 =====================
@@ -7691,7 +7695,7 @@
 go to ``http://192.168.7.2:3000`` and you see the following:
 
 .. image:: figures/cute-files-npm-example.png
-   :align: center
+   :width: 100%
 
 You can find the recipe in ``workspace/recipes/cute-files``. You can use
 the recipe in any layer you choose.
@@ -8215,6 +8219,7 @@
 
 .. image:: figures/buildhistory.png
    :align: center
+   :width: 50%
 
 At the top level, there is a ``metadata-revs`` file that lists the
 revisions of the repositories for the enabled layers when the build was
@@ -8555,7 +8560,7 @@
 Here is a sample screenshot of the interface:
 
 .. image:: figures/buildhistory-web.png
-   :align: center
+   :width: 100%
 
 Performing Automated Runtime Testing
 ====================================
@@ -9214,7 +9219,7 @@
    to run specific tasks in the build chain. It can be useful to run
    tasks "out-of-order" when trying isolate build issues.
 
--  ":ref:`dev-manual/common-tasks:general bitbake problems`" describes how
+-  ":ref:`dev-manual/common-tasks:general BitBake problems`" describes how
    to use BitBake's ``-D`` debug output option to reveal more about what
    BitBake is doing during the build.
 
@@ -9409,7 +9414,7 @@
 
    -  DOT files use a plain text format. The graphs generated using the
       ``bitbake -g`` command are often so large as to be difficult to
-      read without special pruning (e.g. with Bitbake's ``-I`` option)
+      read without special pruning (e.g. with BitBake's ``-I`` option)
       and processing. Despite the form and size of the graphs, the
       corresponding ``.dot`` files can still be possible to read and
       provide useful information.
@@ -10177,10 +10182,9 @@
 
 2. *Configure the system to include gdbserver in the target filesystem:*
 
-   Make the following addition in either your ``local.conf`` file or in
-   an image recipe::
+   Make the following addition in your ``local.conf`` file::
 
-      IMAGE_INSTALL:append = " gdbserver"
+      EXTRA_IMAGE_FEATURES:append = " tools-debug"
 
    The change makes
    sure the ``gdbserver`` package is included.
@@ -10227,14 +10231,14 @@
 
       $ mkdir debugfs
       $ cd debugfs
-      $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2
-      $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2
+      $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2
+      $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2
 
 5. *Set up GDB:*
 
    Install the SDK (if you built one) and then source the correct
    environment file. Sourcing the environment file puts the SDK in your
-   ``PATH`` environment variable.
+   ``PATH`` environment variable and sets ``$GDB`` to the SDK's debugger.
 
    If you are using the build system, Gdb is located in
    `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb``
@@ -10313,24 +10317,20 @@
 
 To support this kind of debugging, you need do the following:
 
--  Ensure that GDB is on the target. You can do this by adding "gdb" to
-   :term:`IMAGE_INSTALL`::
+-  Ensure that GDB is on the target. You can do this by making
+   the following addition to your ``local.conf`` file::
 
-      IMAGE_INSTALL:append = " gdb"
+      EXTRA_IMAGE_FEATURES:append = " tools-debug"
 
-   Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
+-  Ensure that debug symbols are present. You can do so by adding the
+   corresponding ``-dbg`` package to :term:`IMAGE_INSTALL`::
 
-      IMAGE_FEATURES:append = " tools-debug"
+      IMAGE_INSTALL:append = " packagename-dbg"
 
--  Ensure that debug symbols are present. You can make sure these
-   symbols are present by installing ``-dbg``::
-
-      IMAGE_INSTALL:append = "packagename-dbg"
-
-   Alternatively, you can do the following to include
+   Alternatively, you can add the following to ``local.conf`` to include
    all the debug symbols::
 
-      IMAGE_FEATURES:append = " dbg-pkgs"
+      EXTRA_IMAGE_FEATURES:append = " dbg-pkgs"
 
 .. note::
 
@@ -10565,7 +10565,7 @@
 
 -  *poky "master-next" branch:* This branch is part of the
    :yocto_git:`poky </poky/>` repository and combines proposed
-   changes to bitbake, the core metadata and the poky distro.
+   changes to BitBake, the core metadata and the poky distro.
 
 Similarly, stable branches maintained by the project may have corresponding
 ``-next`` branches which collect proposed changes. For example,
@@ -11442,7 +11442,7 @@
    Please choose one that you want to use and enable the spdx task. You have to
    add some config options in ``local.conf`` file in your :term:`Build
    Directory`. Here is an example showing how to generate spdx files
-   during bitbake using the fossology-python.bbclass::
+   during BitBake using the fossology-python.bbclass::
 
       # Select fossology-python.bbclass.
       INHERIT += "fossology-python"
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index 96fabac..8cf3ebe 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -496,7 +496,7 @@
 
 6. *Optimize your WSLv2 storage often:* 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
+   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
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index a5dd02c..dc3345a 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -1062,7 +1062,7 @@
    contents::
 
       FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
-      SRC_URI:append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
+      SRC_URI:append = " file://0001-calibrate.c-Added-some-printk-statements.patch"
 
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find the patch file.
@@ -1560,7 +1560,7 @@
    on building the kernel image when using ``devtool``, see the
    ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
    section. For
-   information on building the kernel image when using Bitbake, see the
+   information on building the kernel image when using BitBake, see the
    ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
    section.
 
diff --git a/poky/documentation/kernel-dev/concepts-appx.rst b/poky/documentation/kernel-dev/concepts-appx.rst
index 910318e..b3a2f3a 100644
--- a/poky/documentation/kernel-dev/concepts-appx.rst
+++ b/poky/documentation/kernel-dev/concepts-appx.rst
@@ -221,7 +221,7 @@
 The following illustration shows the conceptual Yocto Linux kernel.
 
 .. image:: figures/kernel-architecture-overview.png
-   :align: center
+   :width: 100%
 
 In the illustration, the "Kernel.org Branch Point" marks the specific
 spot (or Linux kernel release) from which the Yocto Linux kernel is
@@ -318,12 +318,13 @@
 image.
 
 The following figure shows the temporary file structure created on your
-host system when you build the kernel using Bitbake. This
+host system when you build the kernel using BitBake. This
 :term:`Build Directory` contains all the
 source files used during the build.
 
 .. image:: figures/kernel-overview-2-generic.png
    :align: center
+   :width: 70%
 
 Again, for additional information on the Yocto Project kernel's
 architecture and its branching strategy, see the
diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst
index e406f6e..b9ce7f2 100644
--- a/poky/documentation/kernel-dev/intro.rst
+++ b/poky/documentation/kernel-dev/intro.rst
@@ -106,7 +106,7 @@
 general information and references for further information.
 
 .. image:: figures/kernel-dev-flow.png
-   :align: center
+   :width: 100%
 
 1. *Set up Your Host Development System to Support Development Using the
    Yocto Project*: See the ":doc:`/dev-manual/start`" section in
diff --git a/poky/documentation/migration-guides/migration-2.2.rst b/poky/documentation/migration-guides/migration-2.2.rst
index 10aa2d0..fe7bc2c 100644
--- a/poky/documentation/migration-guides/migration-2.2.rst
+++ b/poky/documentation/migration-guides/migration-2.2.rst
@@ -70,7 +70,7 @@
 
 The metadata is now required to use Python 3 syntax. For help preparing
 metadata, see any of the many Python 3 porting guides available.
-Alternatively, you can reference the conversion commits for Bitbake and
+Alternatively, you can reference the conversion commits for BitBake and
 you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are
 particular areas of interest:
 
diff --git a/poky/documentation/migration-guides/migration-2.7.rst b/poky/documentation/migration-guides/migration-2.7.rst
index ae70353..1b8f1ce 100644
--- a/poky/documentation/migration-guides/migration-2.7.rst
+++ b/poky/documentation/migration-guides/migration-2.7.rst
@@ -15,7 +15,7 @@
    functions (e.g. ``def funcname:``) in the metadata for tab
    indentation. If found, BitBake produces a warning.
 
--  Bitbake now checks
+-  BitBake now checks
    :term:`BBFILE_COLLECTIONS` for duplicate
    entries and triggers an error if any are found.
 
diff --git a/poky/documentation/migration-guides/migration-3.0.rst b/poky/documentation/migration-guides/migration-3.0.rst
index 50d6758..1219edf 100644
--- a/poky/documentation/migration-guides/migration-3.0.rst
+++ b/poky/documentation/migration-guides/migration-3.0.rst
@@ -152,7 +152,7 @@
 
 .. _migration-3.0-bitbake-changes:
 
-Bitbake Changes
+BitBake Changes
 ---------------
 
 The following BitBake changes have occurred.
diff --git a/poky/documentation/migration-guides/migration-3.2.rst b/poky/documentation/migration-guides/migration-3.2.rst
index d593eff..a376ece 100644
--- a/poky/documentation/migration-guides/migration-3.2.rst
+++ b/poky/documentation/migration-guides/migration-3.2.rst
@@ -86,7 +86,7 @@
 dependencies (e.g. in :term:`RDEPENDS` and :term:`RRECOMMENDS` values)
 where the dependency is conditionally added.
 
-If you have anonymous python or in-line python conditionally adding
+If you have anonymous Python or in-line Python conditionally adding
 dependencies in your custom recipes, and you intend for those recipes to
 work with multilib, then you will need to ensure that ``${MLPREFIX}``
 is prefixed on the package names in the dependencies, for example
@@ -149,7 +149,7 @@
 Packaging changes
 -----------------
 
-- ``python3``: the ``urllib`` python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package.
+- ``python3``: the ``urllib`` Python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package.
 
 - ``iptables``: ``iptables-apply`` and ``ip6tables-apply`` have been split out to their own package to avoid a bash dependency in the main ``iptables`` package
 
@@ -283,7 +283,7 @@
 ---------------------------------------------------------------------------
 
 The defaults for the following image artifact name variables have been moved
-from bitbake.conf to a new ``image-artifact-names`` class:
+from ``bitbake.conf`` to a new ``image-artifact-names`` class:
 
 - :term:`IMAGE_BASENAME`
 - :term:`IMAGE_LINK_NAME`
diff --git a/poky/documentation/migration-guides/migration-3.3.rst b/poky/documentation/migration-guides/migration-3.3.rst
index 1eb494c..22562da 100644
--- a/poky/documentation/migration-guides/migration-3.3.rst
+++ b/poky/documentation/migration-guides/migration-3.3.rst
@@ -76,7 +76,7 @@
 
 .. _migration-3.3-distutils-path:
 
-``setup.py`` path for python modules
+``setup.py`` path for Python modules
 ------------------------------------
 
 In a Python module, sometimes ``setup.py`` can be buried deep in the
@@ -133,7 +133,7 @@
 - ``procps``: split ``ps`` and ``sysctl`` into their own packages
 - ``rpm``: split build and extra functionality into separate packages
 - ``sudo``: split ``sudo`` binary into ``sudo-sudo`` and libs into ``sudo-lib``
-- ``systemtap``: examples, python scripts and runtime material split out
+- ``systemtap``: examples, Python scripts and runtime material split out
 - ``util-linux``: ``libuuid`` has been split out to its own
   ``util-linux-libuuid`` recipe (and corresponding packages) to avoid circular
   dependencies if ``libgcrypt`` support is enabled in ``util-linux``.
diff --git a/poky/documentation/migration-guides/migration-3.4.rst b/poky/documentation/migration-guides/migration-3.4.rst
index d57c955..8db43a1 100644
--- a/poky/documentation/migration-guides/migration-3.4.rst
+++ b/poky/documentation/migration-guides/migration-3.4.rst
@@ -233,7 +233,7 @@
 Miscellaneous
 ~~~~~~~~~~~~~
 
-- Certificates are now properly checked when bitbake fetches sources
+- Certificates are now properly checked when BitBake fetches sources
   over HTTPS. If you receive errors as a result for your custom recipes,
   you will need to use a mirror or address the issue with the operators
   of the server in question.
diff --git a/poky/documentation/migration-guides/release-3.4.rst b/poky/documentation/migration-guides/release-3.4.rst
index 81476c4..6602310 100644
--- a/poky/documentation/migration-guides/release-3.4.rst
+++ b/poky/documentation/migration-guides/release-3.4.rst
@@ -7,4 +7,6 @@
    release-notes-3.4
    release-notes-3.4.1
    release-notes-3.4.2
+   release-notes-3.4.3
+   release-notes-3.4.4
 
diff --git a/poky/documentation/migration-guides/release-notes-3.4.1.rst b/poky/documentation/migration-guides/release-notes-3.4.1.rst
index b122887..0503f29 100644
--- a/poky/documentation/migration-guides/release-notes-3.4.1.rst
+++ b/poky/documentation/migration-guides/release-notes-3.4.1.rst
@@ -46,7 +46,7 @@
 -  bitbake: tests/fetch: Update pcre.org address after github changes
 -  bitbake: tests/runqueue: Ensure hashserv exits before deleting files
 -  bitbake: utils: Handle lockfile filenames that are too long for filesystems
--  bootchart2: Don't compile python modules
+-  bootchart2: Don't compile Python modules
 -  build-appliance-image: Update to honister head revision
 -  buildhistory: Fix package output files for SDKs
 -  busybox: 1.34.0 -> 1.34.1
diff --git a/poky/documentation/migration-guides/release-notes-3.4.3.rst b/poky/documentation/migration-guides/release-notes-3.4.3.rst
new file mode 100644
index 0000000..5e118d9
--- /dev/null
+++ b/poky/documentation/migration-guides/release-notes-3.4.3.rst
@@ -0,0 +1,197 @@
+Release notes for 3.4.3 (honister)
+----------------------------------
+
+Security Fixes in 3.4.3
+~~~~~~~~~~~~~~~~~~~~~~~
+
+-  ghostscript: fix :cve:`2021-3781`
+-  ghostscript: fix :cve:`2021-45949`
+-  tiff: Add backports for two CVEs from upstream (:cve:`2022-0561` & :cve:`2022-0562`)
+-  gcc : Fix :cve:`2021-46195`
+-  virglrenderer: fix `CVE-2022-0135 <https://security-tracker.debian.org/tracker/CVE-2022-0135>`__ and `CVE-2022-0175 <https://security-tracker.debian.org/tracker/CVE-2022-0175>`__
+-  binutils: Add fix for :cve:`2021-45078`
+
+
+Fixes in 3.4.3
+~~~~~~~~~~~~~~
+
+-  Revert "cve-check: add lockfile to task"
+-  asciidoc: update git repository
+-  bitbake: build: Tweak exception handling for setscene tasks
+-  bitbake: contrib: Fix hash server Dockerfile dependencies
+-  bitbake: cooker: Improve parsing failure from handled exception usability
+-  bitbake: data_smart: Fix overrides file/line message additions
+-  bitbake: fetch2: ssh: username and password are optional
+-  bitbake: tests/fetch: Handle upstream master -> main branch change
+-  bitbake: utils: Ensure shell function failure in python logging is correct
+-  build-appliance-image: Update to honister head revision
+-  build-appliance-image: Update to honister head revision
+-  coreutils: remove obsolete ignored CVE list
+-  crate-fetch: fix setscene failures
+-  cups: Add --with-dbusdir to EXTRA_OECONF for deterministic build
+-  cve-check: create directory of CVE_CHECK_MANIFEST before copy
+-  cve-check: get_cve_info should open the database read-only
+-  default-distrovars.inc: Switch connectivity check to a yoctoproject.org page
+-  depmodwrapper-cross: add config directory option
+-  devtool: deploy-target: Remove stripped binaries in pseudo context
+-  devtool: explicitly set main or master branches in upgrades when available
+-  docs: fix hardcoded link warning messages
+-  documentation: conf.py: update for 3.4.2
+-  documentation: prepare for 3.4.3 release
+-  expat: Upgrade to 2.4.7
+-  gcc-target: fix glob to remove gcc-<version> binary
+-  gcsections: add nativesdk-cairo to exclude list
+-  go: update to 1.16.15
+-  gst-devtools: 1.18.5 -> 1.18.6
+-  gst-examples: 1.18.5 -> 1.18.6
+-  gstreamer1.0-libav: 1.18.5 -> 1.18.6
+-  gstreamer1.0-omx: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-bad: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-base: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-good: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-ugly: 1.18.5 -> 1.18.6
+-  gstreamer1.0-python: 1.18.5 -> 1.18.6
+-  gstreamer1.0-rtsp-server: 1.18.5 -> 1.18.6
+-  gstreamer1.0-vaapi: 1.18.5 -> 1.18.6
+-  gstreamer1.0: 1.18.5 -> 1.18.6
+-  harfbuzz: upgrade 2.9.0 -> 2.9.1
+-  initramfs-framework: unmount automounts before switch_root
+-  kernel-devsrc: do not copy Module.symvers file during install
+-  libarchive : update to 3.5.3
+-  libpcap: Disable DPDK explicitly
+-  libxml-parser-perl: Add missing RDEPENDS
+-  linux-firmware: upgrade 20211216 -> 20220209
+-  linux-yocto/5.10: Fix ramoops/ftrace
+-  linux-yocto/5.10: features/zram: remove CONFIG_ZRAM_DEF_COMP
+-  linux-yocto/5.10: fix dssall build error with binutils 2.3.8
+-  linux-yocto/5.10: ppc/riscv: fix build with binutils 2.3.8
+-  linux-yocto/5.10: update genericx86* machines to v5.10.99
+-  linux-yocto/5.10: update to v5.10.103
+-  mc: fix build if ncurses have been configured without wide characters
+-  oeqa/buildtools: Switch to our webserver instead of example.com
+-  patch.py: Prevent git repo reinitialization
+-  perl: Improve and update module RPDEPENDS
+-  poky.conf: bump version for 3.4.3 honister release
+-  qemuboot: Fix build error if UNINATIVE_LOADER is unset
+-  quilt: Disable external sendmail for deterministic build
+-  recipetool: Fix circular reference in SRC_URI
+-  releases: update to include 3.3.5
+-  releases: update to include 3.4.2
+-  rootfs-postcommands: amend systemd_create_users add user to group check
+-  ruby: update 3.0.2 -> 3.0.3
+-  scripts/runqemu-ifdown: Don't treat the last iptables command as special
+-  sdk: fix search for dynamic loader
+-  selftest: recipetool: Correct the URI for socat
+-  sstate: inside the threadedpool don't write to the shared localdata
+-  uninative: Upgrade to 3.5
+-  util-linux: upgrade to 2.37.4
+-  vim: Update to 8.2.4524 for further CVE fixes
+-  wic: Use custom kernel path if provided
+-  wireless-regdb: upgrade 2021.08.28 -> 2022.02.18
+-  zip: modify when match.S is built
+
+Contributors to 3.4.3
+~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexander Kanavin
+-  Anuj Mittal
+-  Bill Pittman
+-  Bruce Ashfield
+-  Chee Yang Lee
+-  Christian Eggers
+-  Daniel Gomez
+-  Daniel Müller
+-  Daniel Wagenknecht
+-  Florian Amstutz
+-  Joe Slater
+-  Jose Quaresma
+-  Justin Bronder
+-  Lee Chee Yang
+-  Michael Halstead
+-  Michael Opdenacker
+-  Oleksandr Ocheretnyi
+-  Oleksandr Suvorov
+-  Pavel Zhukov
+-  Peter Kjellerstedt
+-  Richard Purdie
+-  Robert Yang
+-  Ross Burton
+-  Sakib Sajal
+-  Saul Wold
+-  Sean Anderson
+-  Stefan Herbrechtsmeier
+-  Tamizharasan Kumar
+-  Tean Cunningham
+-  Zoltán Böszörményi
+-  pgowda
+-  wangmy
+
+Repositories / Downloads for 3.4.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/poky/
+-  Branch: :yocto_git:`honister </poky/log/?h=honister>`
+-  Tag: `yocto-3.4.3 <https://git.yoctoproject.org/poky/tag/?h=yocto-3.4.3>`__
+-  Git Revision: :yocto_git:`ee68ae307fd951b9de6b31dc6713ea29186b7749 </poky/commit/?id=ee68ae307fd951b9de6b31dc6713ea29186b7749>`
+-  Release Artefact: poky-ee68ae307fd951b9de6b31dc6713ea29186b7749
+-  sha: 92c3d73c3e74f0e1d5c2ab2836ce3a3accbe47772cea70df3755845e0db1379b
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/poky-ee68ae307fd951b9de6b31dc6713ea29186b7749.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/poky-ee68ae307fd951b9de6b31dc6713ea29186b7749.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`honister </openembedded-core/log/?h=honister>`
+-  Tag: :oe_git:`yocto-3.4.3 </openembedded-core/tag/?h=yocto-3.4.3>`
+-  Git Revision: :oe_git:`ebca8f3ac9372b7ebb3d39e8f7f930b63b481448 </openembedded-core/commit/?id=ebca8f3ac9372b7ebb3d39e8f7f930b63b481448>`
+-  Release Artefact: oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448
+-  sha: f28e503f6f6c0bcd9192dbd528f8e3c7bcea504c089117e0094d9a4f315f4b9f
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/meta-mingw
+-  Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.3 </meta-mingw/tag/?h=yocto-3.4.3>`
+-  Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>`
+-  Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8
+-  sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/meta-gplv2
+-  Branch: :yocto_git:`honister </meta-gplv2/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.3 </meta-gplv2/tag/?h=yocto-3.4.3>`
+-  Git Revision: :yocto_git:`f04e4369bf9dd3385165281b9fa2ed1043b0e400 </meta-gplv2/commit/?id=f04e4369bf9dd3385165281b9fa2ed1043b0e400>`
+-  Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400
+-  sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`1.52 </bitbake/log/?h=1.52>`
+-  Tag: :oe_git:`yocto-3.4.3 </bitbake/tag/?h=yocto-3.4.3>`
+-  Git Revision: :oe_git:`43dcb2b2a2b95a5c959be57bca94fb7190ea6257 </bitbake/commit/?id=43dcb2b2a2b95a5c959be57bca94fb7190ea6257>`
+-  Release Artefact: bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257
+-  sha: 92497ff97fed81dcc6d3e202969fb63ca983a8f5d9d91cafc6aee88312f79cf9
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/yocto-docs
+-  Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.3 </yocto-docs/tag/?h=yocto-3.4.3>`
+-  Git Revision: :yocto_git:`15f46f97d9cad558c19fc1dc19cfbe3720271d04 </yocto-docs/commit/?15f46f97d9cad558c19fc1dc19cfbe3720271d04>`
diff --git a/poky/documentation/migration-guides/release-notes-3.4.4.rst b/poky/documentation/migration-guides/release-notes-3.4.4.rst
new file mode 100644
index 0000000..91beba0
--- /dev/null
+++ b/poky/documentation/migration-guides/release-notes-3.4.4.rst
@@ -0,0 +1,155 @@
+Release notes for 3.4.4 (honister)
+----------------------------------
+
+Security Fixes in 3.4.4
+~~~~~~~~~~~~~~~~~~~~~~~
+
+-  tiff: fix :cve:`2022-0865`, :cve:`2022-0891`, :cve:`2022-0907`, :cve:`2022-0908`, :cve:`2022-0909` and :cve:`2022-0924`
+-  xz: fix `CVE-2022-1271 <https://security-tracker.debian.org/tracker/CVE-2022-1271>`__
+-  unzip: fix `CVE-2021-4217 <https://security-tracker.debian.org/tracker/CVE-2021-4217>`__
+-  zlib: fix :cve:`2018-25032`
+-  grub: ignore :cve:`2021-46705`
+
+Fixes in 3.4.4
+~~~~~~~~~~~~~~
+
+-  alsa-tools: Ensure we install correctly
+-  bitbake.conf: mark all directories as safe for git to read
+-  bitbake: knotty: display active tasks when printing keepAlive() message
+-  bitbake: knotty: reduce keep-alive timeout from 5000s (83 minutes) to 10 minutes
+-  bitbake: server/process: Disable gc around critical section
+-  bitbake: server/xmlrpcserver: Add missing xmlrpcclient import
+-  bitbake: toaster: Fix IMAGE_INSTALL issues with _append vs :append
+-  bitbake: toaster: fixtures replace gatesgarth
+-  build-appliance-image: Update to honister head revision
+-  conf.py/poky.yaml: Move version information to poky.yaml and read in conf.py
+-  conf/machine: fix QEMU x86 sound options
+-  devupstream: fix handling of SRC_URI
+-  documentation: update for 3.4.4 release
+-  externalsrc/devtool: Fix to work with fixed export funcition flags handling
+-  gmp: add missing COPYINGv3
+-  gnu-config: update SRC_URI
+-  libxml2: fix CVE-2022-23308 regression
+-  libxml2: move to gitlab.gnome.org
+-  libxml2: update to 2.9.13
+-  libxshmfence: Correct LICENSE to HPND
+-  license_image.bbclass: close package.manifest file
+-  linux-firmware: correct license for ar3k firmware
+-  linux-firmware: upgrade 20220310 -> 20220411
+-  linux-yocto-rt/5.10: update to -rt61
+-  linux-yocto/5.10: cfg/debug: add configs for kcsan
+-  linux-yocto/5.10: split vtpm for more granular inclusion
+-  linux-yocto/5.10: update to v5.10.109
+-  linux-yocto: nohz_full boot arg fix
+-  oe-pkgdata-util: Adapt to the new variable override syntax
+-  oeqa/selftest/devtool: ensure Git username is set before upgrade tests
+-  poky.conf: bump version for 3.4.4 release
+-  pseudo: Add patch to workaround paths with crazy lengths
+-  pseudo: Fix handling of absolute links
+-  sanity: Add warning for local hasheqiv server with remote sstate mirrors
+-  scripts/runqemu: Fix memory limits for qemux86-64
+-  shadow-native: Simplify and fix syslog disable patch
+-  tiff: Add marker for CVE-2022-1056 being fixed
+-  toaster: Fix broken overrides usage
+-  u-boot: Inherit pkgconfig
+-  uninative: Upgrade to 3.6 with gcc 12 support
+-  vim: Upgrade 8.2.4524 -> 8.2.4681
+-  virglrenderer: update SRC_URI
+-  webkitgtk: update to 2.32.4
+-  wireless-regdb: upgrade 2022.02.18 -> 2022.04.08
+
+Known Issues
+~~~~~~~~~~~~
+
+There were a couple of known autobuilder intermittent bugs that occurred during release testing but these are not regressions in the release.
+
+Contributors to 3.4.4
+~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexandre Belloni
+-  Anuj Mittal
+-  Bruce Ashfield
+-  Chee Yang Lee
+-  Dmitry Baryshkov
+-  Joe Slater
+-  Konrad Weihmann
+-  Martin Jansa
+-  Michael Opdenacker
+-  Minjae Kim
+-  Peter Kjellerstedt
+-  Ralph Siemsen
+-  Richard Purdie
+-  Ross Burton
+-  Tim Orling
+-  wangmy
+-  zhengruoqin
+
+Repositories / Downloads for 3.4.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/poky/
+-  Branch: :yocto_git:`honister </poky/log/?h=honister>`
+-  Tag: `yocto-3.4.4 <https://git.yoctoproject.org/poky/tag/?h=yocto-3.4.4>`__
+-  Git Revision: :yocto_git:`780eeec8851950ee6ac07a2a398ba937206bd2e4 </poky/commit/?id=780eeec8851950ee6ac07a2a398ba937206bd2e4>`
+-  Release Artefact: poky-780eeec8851950ee6ac07a2a398ba937206bd2e4
+-  sha: 09558927064454ec2492da376156b716d9fd14aae57196435d742db7bfdb4b95
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/poky-780eeec8851950ee6ac07a2a398ba937206bd2e4.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/poky-780eeec8851950ee6ac07a2a398ba937206bd2e4.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`honister </openembedded-core/log/?h=honister>`
+-  Tag: :oe_git:`yocto-3.4.4 </openembedded-core/tag/?h=yocto-3.4.4>`
+-  Git Revision: :oe_git:`1a6f5e27249afb6fb4d47c523b62b5dd2482a69d </openembedded-core/commit/?id=1a6f5e27249afb6fb4d47c523b62b5dd2482a69d>`
+-  Release Artefact: oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d
+-  sha: b8354ca457756384139a579b9e51f1ba854013c99add90c0c4c6ef68421fede5
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/meta-mingw
+-  Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.4 </meta-mingw/tag/?h=yocto-3.4.4>`
+-  Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>`
+-  Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8
+-  sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/meta-gplv2
+-  Branch: :yocto_git:`honister </meta-gplv2/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.4 </meta-gplv2/tag/?h=yocto-3.4.4>`
+-  Git Revision: :yocto_git:`f04e4369bf9dd3385165281b9fa2ed1043b0e400 </meta-gplv2/commit/?id=f04e4369bf9dd3385165281b9fa2ed1043b0e400>`
+-  Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400
+-  sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`1.52 </bitbake/log/?h=1.52>`
+-  Tag: :oe_git:`yocto-3.4.4 </bitbake/tag/?h=yocto-3.4.3>`
+-  Git Revision: :oe_git:`c2d8f9b2137bd4a98eb0f51519493131773e7517 </bitbake/commit/?id=c2d8f9b2137bd4a98eb0f51519493131773e7517>`
+-  Release Artefact: bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517
+-  sha: a8b6217f2d63975bbf49f430e11046608023ee2827faa893b15d9a0d702cf833
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/yocto-docs
+-  Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.4 </yocto-docs/tag/?h=yocto-3.4.4>`
+-  Git Revision: :yocto_git:`5ead7d39aaf9044078dff27f462e29a8e31d89e4 </yocto-docs/commit/?5ead7d39aaf9044078dff27f462e29a8e31d89e4>`
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 6c34197..016577e 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -166,7 +166,7 @@
 process, and metadata logical blocks that make up the workflow.
 
 .. image:: figures/YP-flow-diagram.png
-   :align: center
+   :width: 100%
 
 In general, the build's workflow consists of several functional areas:
 
@@ -209,7 +209,7 @@
 figure <overview-manual/concepts:openembedded build system concepts>`:
 
 .. image:: figures/user-configuration.png
-   :align: center
+   :width: 100%
 
 BitBake needs some basic configuration files in order to complete a
 build. These files are ``*.conf`` files. The minimally necessary ones
@@ -313,7 +313,7 @@
 
 The files ``site.conf`` and ``auto.conf`` are not created by the
 environment initialization script. If you want the ``site.conf`` file,
-you need to create that yourself. The ``auto.conf`` file is typically
+you need to create it yourself. The ``auto.conf`` file is typically
 created by an autobuilder:
 
 -  *site.conf:* You can use the ``conf/site.conf`` configuration
@@ -321,17 +321,7 @@
    you had several build environments and they shared some common
    features. You can set these default build properties here. A good
    example is perhaps the packaging format to use through the
-   :term:`PACKAGE_CLASSES`
-   variable.
-
-   One useful scenario for using the ``conf/site.conf`` file is to
-   extend your :term:`BBPATH` variable
-   to include the path to a ``conf/site.conf``. Then, when BitBake looks
-   for Metadata using :term:`BBPATH`, it finds the ``conf/site.conf`` file
-   and applies your common configurations found in the file. To override
-   configurations in a particular build directory, alter the similar
-   configurations within that build directory's ``conf/local.conf``
-   file.
+   :term:`PACKAGE_CLASSES` variable.
 
 -  *auto.conf:* The file is usually created and written to by an
    autobuilder. The settings put into the file are typically the same as
@@ -401,6 +391,7 @@
 
 .. image:: figures/layer-input.png
    :align: center
+   :width: 70%
 
 In general, all layers have a similar structure. They all contain a
 licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed,
@@ -551,6 +542,7 @@
 
 .. image:: figures/source-input.png
    :align: center
+   :width: 70%
 
 Upstream Project Releases
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -629,7 +621,7 @@
 the build system. Here is a more detailed look at the area:
 
 .. image:: figures/package-feeds.png
-   :align: center
+   :width: 100%
 
 Package feeds are an intermediary step in the build process. The
 OpenEmbedded build system provides classes to generate different package
@@ -702,7 +694,7 @@
 code:
 
 .. image:: figures/source-fetching.png
-   :align: center
+   :width: 100%
 
 The :ref:`ref-tasks-fetch` and
 :ref:`ref-tasks-unpack` tasks fetch
@@ -790,7 +782,7 @@
 and applies them to the source files:
 
 .. image:: figures/patching.png
-   :align: center
+   :width: 100%
 
 The :ref:`ref-tasks-patch` task uses a
 recipe's :term:`SRC_URI` statements
@@ -831,7 +823,7 @@
 to a holding area (staged) in preparation for packaging:
 
 .. image:: figures/configuration-compile-autoreconf.png
-   :align: center
+   :width: 100%
 
 This step in the build process consists of the following tasks:
 
@@ -889,7 +881,7 @@
 analyzes the results and splits the output into packages:
 
 .. image:: figures/analysis-for-package-splitting.png
-   :align: center
+   :width: 100%
 
 The :ref:`ref-tasks-package` and
 :ref:`ref-tasks-packagedata`
@@ -968,7 +960,7 @@
 system uses BitBake to generate the root filesystem image:
 
 .. image:: figures/image-generation.png
-   :align: center
+   :width: 100%
 
 The image generation process consists of several stages and depends on
 several tasks and variables. The
@@ -1086,7 +1078,7 @@
 the extensible SDK (eSDK):
 
 .. image:: figures/sdk-generation.png
-   :align: center
+   :width: 100%
 
 .. note::
 
@@ -1262,6 +1254,7 @@
 
 .. image:: figures/images.png
    :align: center
+   :width: 75%
 
 .. note::
 
@@ -1321,7 +1314,7 @@
 closer look at this output:
 
 .. image:: figures/sdk.png
-   :align: center
+   :width: 100%
 
 The specific form of this output is a set of files that includes a
 self-extracting SDK installer (``*.sh``), host and target manifest
@@ -1439,7 +1432,7 @@
 toolchain construction and use.
 
 .. image:: figures/cross-development-toolchains.png
-   :align: center
+   :width: 100%
 
 Most of the work occurs on the Build Host. This is the machine used to
 build images and generally work within the the Yocto Project
@@ -2146,7 +2139,7 @@
 
       By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
       ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
-      bitbake.conf) includes "${PN}".
+      ``bitbake.conf``) includes "${PN}".
 
    To ensure that the dependency chain is never broken, ``-dev`` and
    ``-dbg`` packages are always generated by default, even if the
diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
index e171d7a..f1001e0 100644
--- a/poky/documentation/overview-manual/development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -176,7 +176,7 @@
    repositories for each of these areas.
 
    .. image:: figures/source-repos.png
-      :align: center
+      :width: 100%
 
    For steps on how to view and access these upstream Git repositories,
    see the ":ref:`dev-manual/start:accessing source repositories`"
@@ -191,6 +191,7 @@
 
    .. image:: figures/index-downloads.png
       :align: center
+      :width: 50%
 
    For steps on how to view and access these files, see the
    ":ref:`dev-manual/start:accessing index of releases`"
@@ -205,7 +206,7 @@
    :yocto_dl:`Index of /releases: </releases>` area.
 
    .. image:: figures/yp-download.png
-      :align: center
+      :width: 100%
 
    For steps on how to use the "DOWNLOADS" page, see the
    ":ref:`dev-manual/start:using the downloads page`"
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index e574dfa..a2e0862 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -24,7 +24,7 @@
 platforms as well as software stacks that can be maintained and scaled.
 
 .. image:: figures/key-dev-elements.png
-    :align: center
+    :width: 100%
 
 For further introductory information on the Yocto Project, you might be
 interested in this
@@ -638,7 +638,7 @@
 The following figure illustrates what generally comprises Poky:
 
 .. image:: figures/poky-reference-distribution.png
-    :align: center
+    :width: 100%
 
 -  BitBake is a task executor and scheduler that is the heart of the
    OpenEmbedded build system.
@@ -688,8 +688,8 @@
 
 One of the most powerful properties of Poky is that every aspect of a
 build is controlled by the metadata. You can use metadata to augment
-these base image types by adding metadata
-`layers <overview-manual/yp-intro:the yocto project layer model>` that extend
+these base image types by adding metadata :ref:`layers
+<overview-manual/yp-intro:the yocto project layer model>` that extend
 functionality.
 These layers can provide, for example, an additional software stack for
 an image type, add a board support package (BSP) for additional
@@ -720,7 +720,7 @@
 workflow:
 
 .. image:: figures/YP-flow-diagram.png
-    :align: center
+    :width: 100%
 
 Following is a brief summary of the "workflow":
 
diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst
index fb1553d..0ff9d92 100644
--- a/poky/documentation/profile-manual/usage.rst
+++ b/poky/documentation/profile-manual/usage.rst
@@ -197,6 +197,7 @@
 
 .. image:: figures/perf-wget-flat-stripped.png
    :align: center
+   :width: 70%
 
 The above screenshot displays a 'flat' profile, one entry for each
 'bucket' corresponding to the functions that were profiled during the
@@ -230,6 +231,7 @@
 
 .. image:: figures/perf-wget-g-copy-to-user-expanded-stripped.png
    :align: center
+   :width: 70%
 
 Using the callgraph view, we can actually see not only which functions
 took the most time, but we can also see a summary of how those functions
@@ -266,6 +268,7 @@
 
 .. image:: figures/perf-wget-g-copy-from-user-expanded-stripped.png
    :align: center
+   :width: 70%
 
 The above screenshot shows the other half of the journey for the data -
 from the wget program's userspace buffers to disk. To get the buffers to
@@ -283,6 +286,7 @@
 
 .. image:: figures/perf-wget-busybox-expanded-stripped.png
    :align: center
+   :width: 70%
 
 Again, before we expanded we saw that the function was labeled with a
 hex value instead of a symbol as with most of the kernel entries.
@@ -330,6 +334,7 @@
 
 .. image:: figures/perf-wget-busybox-debuginfo.png
    :align: center
+   :width: 70%
 
 If we expand one of the entries and press 'enter' on a leaf node, we're
 presented with a menu of actions we can take to get more information
@@ -337,6 +342,7 @@
 
 .. image:: figures/perf-wget-busybox-dso-zoom-menu.png
    :align: center
+   :width: 70%
 
 One of these actions allows us to show a view that displays a
 busybox-centric view of the profiled functions (in this case we've also
@@ -344,6 +350,7 @@
 
 .. image:: figures/perf-wget-busybox-dso-zoom.png
    :align: center
+   :width: 70%
 
 Finally, we can see that now that the BusyBox debuginfo is installed,
 the previously unresolved symbol in the ``sys_clock_gettime()`` entry
@@ -354,6 +361,7 @@
 
 .. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
    :align: center
+   :width: 70%
 
 At the lowest level of detail, we can dive down to the assembly level
 and see which instructions caused the most overhead in a function.
@@ -362,6 +370,7 @@
 
 .. image:: figures/perf-wget-busybox-annotate-menu.png
    :align: center
+   :width: 70%
 
 Selecting 'Annotate udhcpc_main', we get a detailed listing of
 percentages by instruction for the udhcpc_main function. From the
@@ -370,6 +379,7 @@
 
 .. image:: figures/perf-wget-busybox-annotate-udhcpc.png
    :align: center
+   :width: 70%
 
 As a segue into tracing, let's try another profile using a different
 counter, something other than the default 'cycles'.
@@ -593,6 +603,7 @@
 
 .. image:: figures/sched-wakeup-profile.png
    :align: center
+   :width: 70%
 
 The screenshot above shows the results of running a profile using
 sched:sched_switch tracepoint, which shows the relative costs of various
@@ -740,7 +751,7 @@
    root@crownbay:~# perf script -g python
    generated Python script: perf-script.py
 
-The skeleton script simply creates a python function for each event type in the
+The skeleton script simply creates a Python function for each event type in the
 perf.data file. The body of each function simply prints the event name along
 with its parameters. For example:
 
@@ -859,7 +870,7 @@
 the right kind of trace data, higher-level profiling-type summaries can
 be derived from it.
 
-Documentation on using the `'perf script' python
+Documentation on using the `'perf script' Python
 binding <https://linux.die.net/man/1/perf-script-python>`__.
 
 System-Wide Tracing and Profiling
@@ -894,6 +905,7 @@
 
 .. image:: figures/perf-systemwide.png
    :align: center
+   :width: 70%
 
 In the snapshot above, we can see callchains that originate in libc, and
 a callchain from Xorg that demonstrates that we're using a proprietary X
@@ -911,6 +923,7 @@
 
 .. image:: figures/perf-report-cycles-u.png
    :align: center
+   :width: 70%
 
 Notice in the screenshot above, we see only userspace entries ([.])
 
@@ -921,6 +934,7 @@
 
 .. image:: figures/perf-systemwide-libc.png
    :align: center
+   :width: 70%
 
 We can also use the system-wide -a switch to do system-wide tracing.
 Here we'll trace a couple of scheduler events::
@@ -1116,6 +1130,7 @@
 
 .. image:: figures/perf-probe-do_fork-profile.png
    :align: center
+   :width: 70%
 
 .. admonition:: Tying it Together
 
@@ -1149,7 +1164,7 @@
 -  The `'perf script'
    manpage <https://linux.die.net/man/1/perf-script>`__.
 
--  Documentation on using the `'perf script' python
+-  Documentation on using the `'perf script' Python
    binding <https://linux.die.net/man/1/perf-script-python>`__.
 
 -  The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__.
@@ -1684,6 +1699,7 @@
 
 .. image:: figures/kernelshark-choose-events.png
    :align: center
+   :width: 70%
 
 Note that these are exactly the same sets of events described in the
 previous trace events subsystem section, and in fact is where trace-cmd
@@ -1699,6 +1715,7 @@
 
 .. image:: figures/kernelshark-output-display.png
    :align: center
+   :width: 70%
 
 Notice that the right-hand pane shows the exact trace-cmd command-line
 that's used to run the trace, along with the results of the trace-cmd
@@ -1710,12 +1727,14 @@
 
 .. image:: figures/kernelshark-i915-display.png
    :align: center
+   :width: 70%
 
 Here's another example, this time a display resulting from tracing 'all
 events':
 
 .. image:: figures/kernelshark-all.png
    :align: center
+   :width: 70%
 
 The tool is pretty self-explanatory, but for more detailed information
 on navigating through the data, see the `kernelshark
@@ -1974,6 +1993,7 @@
 
 .. image:: figures/sysprof-copy-to-user.png
    :align: center
+   :width: 70%
 
 The left pane shows a list of functions and processes. Selecting one of
 those expands that function in the right pane, showing all its callees.
@@ -1988,6 +2008,7 @@
 
 .. image:: figures/sysprof-copy-from-user.png
    :align: center
+   :width: 70%
 
 Similarly, the above is a snapshot of the Sysprof display of a
 copy-from-user callchain.
@@ -1999,6 +2020,7 @@
 
 .. image:: figures/sysprof-callers.png
    :align: center
+   :width: 70%
 
 Double-clicking on one of those functions will in turn change the focus
 to the selected function, and so on.
diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst
index a1a8bcd..10ca70a 100644
--- a/poky/documentation/ref-manual/devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -126,8 +126,7 @@
 The following figure shows the workspace structure:
 
 .. image:: figures/build-workspace-directory.png
-   :align: center
-   :scale: 70%
+   :scale: 100%
 
 .. code-block:: none
 
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index 262b041..12a0855 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -261,7 +261,7 @@
 :ref:`structure-core-script`.
 
 The source ``local.conf.sample`` file used depends on the
-``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/``
+:term:`TEMPLATECONF` script variable, which defaults to ``meta-poky/conf/``
 when you are building from the Yocto Project development environment,
 and to ``meta/conf/`` when you are building from the OpenEmbedded-Core
 environment. Because the script variable points to the source of the
@@ -278,7 +278,7 @@
 
 .. note::
 
-   You can see how the ``TEMPLATECONF`` variable is used by looking at the
+   You can see how the :term:`TEMPLATECONF` variable is used by looking at the
    ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`.
    You can find the Yocto Project version of the ``local.conf.sample`` file in
    the ``meta-poky/conf`` directory.
@@ -300,7 +300,7 @@
 :ref:`structure-core-script`).
 
 As with the ``local.conf`` file, the source ``bblayers.conf.sample``
-file used depends on the ``$TEMPLATECONF`` script variable, which
+file used depends on the :term:`TEMPLATECONF` script variable, which
 defaults to ``meta-poky/conf/`` when you are building from the Yocto
 Project development environment, and to ``meta/conf/`` when you are
 building from the OpenEmbedded-Core environment. Because the script
@@ -315,7 +315,7 @@
 
 .. note::
 
-   You can see how the ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir``
+   You can see how the :term:`TEMPLATECONF` variable is defined by the ``scripts/oe-setup-builddir``
    script in the :term:`Source Directory`. You can find the Yocto Project
    version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/``
    directory.
diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index a2b8763..cb08a75 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -522,7 +522,7 @@
 Starts a shell in which an interactive Python interpreter allows you to
 interact with the BitBake build environment. From within this shell, you
 can directly examine and set bits from the data store and execute
-functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a python development shell`" section in
+functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a Python development shell`" section in
 the Yocto Project Development Tasks Manual for more information about
 using ``pydevshell``.
 
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index f8808cc..367b467 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -3551,7 +3551,7 @@
 
       For more information on :term:`INHERIT`, see the
       :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
-      section in the Bitbake User Manual.
+      section in the BitBake User Manual.
 
    :term:`INHERIT_DISTRO`
       Lists classes that will be inherited at the distribution level. It is
@@ -4064,10 +4064,10 @@
       statements add specific configurations to targeted machine types::
 
          KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
-         KERNEL_FEATURES:append = "${KERNEL_EXTRA_FEATURES}"
-         KERNEL_FEATURES:append:qemuall = "cfg/virtio.scc"
-         KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
-         KERNEL_FEATURES:append:qemux86-64 = "cfg/sound.scc"
+         KERNEL_FEATURES:append = " ${KERNEL_EXTRA_FEATURES}"
+         KERNEL_FEATURES:append:qemuall = " cfg/virtio.scc"
+         KERNEL_FEATURES:append:qemux86 = "  cfg/sound.scc cfg/paravirt_kvm.scc"
+         KERNEL_FEATURES:append:qemux86-64 = " cfg/sound.scc"
 
    :term:`KERNEL_FIT_LINK_NAME`
       The link name of the kernel flattened image tree (FIT) image. This
@@ -4255,7 +4255,7 @@
          SRCREV_machine:core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
          KMACHINE:core2-32-intel-common = "intel-core2-32"
          KBRANCH:core2-32-intel-common = "standard/base"
-         KERNEL_FEATURES:append:core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
+         KERNEL_FEATURES:append:core2-32-intel-common = " ${KERNEL_FEATURES_INTEL_COMMON}"
 
       The :term:`KMACHINE` statement says
       that the kernel understands the machine name as "intel-core2-32".
@@ -7899,6 +7899,21 @@
       toolchain. You can use ``meta-sourcery`` as a template for adding
       support for other external toolchains.
 
+   :term:`TEMPLATECONF`
+      Specifies the directory used by the build system to find templates
+      from which to build the ``bblayers.conf`` and ``local.conf`` files.
+      Use this variable if you wish to customize such files, and the default
+      BitBake targets shown when sourcing the ``oe-init-build-env`` script.
+
+      For details, see the
+      :ref:`dev-manual/common-tasks:creating a custom template configuration directory`
+      section in the Yocto Project Development Tasks manual.
+
+      .. note::
+
+         You must set this variable in the external environment in order
+         for it to work.
+
    :term:`TEST_EXPORT_DIR`
       The location the OpenEmbedded build system uses to export tests when
       the :term:`TEST_EXPORT_ONLY` variable is set
@@ -8752,6 +8767,19 @@
       previous example, some-native-tool would be replaced with an actual
       native tool on which the build would depend.
 
+   :term:`WKS_FILES`
+      Specifies a list of candidate Wic kickstart files to be used by the
+      OpenEmbedded build system to create a partitioned image. Only the
+      first one that is found, from left to right, will be used.
+
+      This is only useful when there are multiple ``.wks`` files that can be
+      used to produce an image. A typical case is when multiple layers are
+      used for different hardware platforms, each supplying a different
+      ``.wks`` file. In this case, you specify all possible ones through
+      :term:`WKS_FILES`.
+
+      If only one ``.wks`` file is used, set :term:`WKS_FILE` instead.
+
    :term:`WORKDIR`
       The pathname of the work directory in which the OpenEmbedded build
       system builds a recipe. This directory is located within the
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index cfc3a7b..08984b2 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -16,6 +16,7 @@
 ******************************
 
 - :yocto_docs:`4.0 Documentation </4.0>`
+- :yocto_docs:`4.0.1 Documentation </4.0.1>`
 
 ******************************
 Release Series 3.4 (honister)
@@ -25,6 +26,7 @@
 - :yocto_docs:`3.4.1 Documentation </3.4.1>`
 - :yocto_docs:`3.4.2 Documentation </3.4.2>`
 - :yocto_docs:`3.4.3 Documentation </3.4.3>`
+- :yocto_docs:`3.4.4 Documentation </3.4.4>`
 
 ******************************
 Release Series 3.3 (hardknott)
@@ -58,6 +60,7 @@
 - :yocto_docs:`3.1.13 Documentation </3.1.13>`
 - :yocto_docs:`3.1.14 Documentation </3.1.14>`
 - :yocto_docs:`3.1.15 Documentation </3.1.15>`
+- :yocto_docs:`3.1.16 Documentation </3.1.16>`
 
 ==========================
  Outdated Release Manuals
diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
index 841abac..ece378c 100644
--- a/poky/documentation/sdk-manual/appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -265,8 +265,7 @@
 script:
 
 .. image:: figures/sdk-installed-standard-sdk-directory.png
-   :scale: 80%
-   :align: center
+   :scale: 100%
 
 The installed SDK consists of an environment setup script for the SDK, a
 configuration file for the target, a version file for the target, and
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index c5970f7..6bb2622 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -233,7 +233,7 @@
 command:
 
 .. image:: figures/sdk-devtool-add-flow.png
-   :align: center
+   :width: 100%
 
 1. *Generating the New Recipe*: The top part of the flow shows three
    scenarios by which you could use ``devtool add`` to generate a recipe
@@ -401,7 +401,7 @@
 command:
 
 .. image:: figures/sdk-devtool-modify-flow.png
-   :align: center
+   :width: 100%
 
 1. *Preparing to Modify the Code*: The top part of the flow shows three
    scenarios by which you could use ``devtool modify`` to prepare to
@@ -620,7 +620,7 @@
 ``devtool upgrade`` command:
 
 .. image:: figures/sdk-devtool-upgrade-flow.png
-   :align: center
+   :width: 100%
 
 1. *Initiate the Upgrade*: The top part of the flow shows the typical
    scenario by which you use the ``devtool upgrade`` command. The
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index 802d3f3..ce00538 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -149,7 +149,7 @@
 Fundamentally, the SDK fits into the development process as follows:
 
 .. image:: figures/sdk-environment.png
-   :align: center
+   :width: 100%
 
 The SDK is installed on any machine and can be used to develop applications,
 images, and kernels. An SDK can even be used by a QA Engineer or Release
diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst
index 276daa9..efef5c8 100644
--- a/poky/documentation/sdk-manual/working-projects.rst
+++ b/poky/documentation/sdk-manual/working-projects.rst
@@ -19,6 +19,7 @@
 
 .. image:: figures/sdk-autotools-flow.png
    :align: center
+   :width: 70%
 
 Follow these steps to create a simple Autotools-based "Hello World"
 project:
@@ -168,6 +169,7 @@
 
 .. image:: figures/sdk-makefile-flow.png
    :align: center
+   :width: 70%
 
 The main point of this section is to explain the following three cases
 regarding variable behavior:
diff --git a/poky/documentation/set_versions.py b/poky/documentation/set_versions.py
index cd02cc7..c409d5e 100755
--- a/poky/documentation/set_versions.py
+++ b/poky/documentation/set_versions.py
@@ -23,7 +23,7 @@
 if len(sys.argv) == 2:
     ourversion = sys.argv[1]
 
-activereleases = ["kirkstone", "honister", "hardknott", "dunfell"]
+activereleases = ["kirkstone", "honister", "dunfell"]
 devbranch = "langdale"
 ltsseries = ["kirkstone", "dunfell"]
 
@@ -211,7 +211,7 @@
             w.write(str(list(release_series.keys())))
             continue
         if "VERSIONS_PLACEHOLDER" in line:
-            w.write("    'dev': { 'title': 'dev (%s)', 'obsolete': false,},\n" % release_series[devbranch])
+            w.write("    'dev': { 'title': 'Unstable (dev)', 'obsolete': false,},\n")
             for branch in activereleases + ([ourseries] if ourseries not in activereleases else []):
                 if branch == devbranch:
                     continue
@@ -223,9 +223,9 @@
                 if branch_versions[-1] != "0":
                     version = version + "." + branch_versions[-1]
                 versions.append(version)
-                w.write("    '%s': {'title': '%s', 'obsolete': %s,},\n" % (version, version, str(branch not in activereleases).lower()))
+                w.write("    '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (version, branch.capitalize(), version, str(branch not in activereleases).lower()))
             if ourversion not in versions and ourseries != devbranch:
-                w.write("    '%s': {'title': '%s', 'obsolete': %s,},\n" % (ourversion, ourversion, str(ourseries not in activereleases).lower()))
+                w.write("    '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (ourversion, ourseries.capitalize(), ourversion, str(ourseries not in activereleases).lower()))
         else:
             w.write(line)
 
diff --git a/poky/documentation/sphinx/yocto-vars.py b/poky/documentation/sphinx/yocto-vars.py
index 8795eee..643c0df 100644
--- a/poky/documentation/sphinx/yocto-vars.py
+++ b/poky/documentation/sphinx/yocto-vars.py
@@ -13,7 +13,7 @@
     import yaml
 except ImportError:
     sys.stderr.write("The Yocto Project Sphinx documentation requires PyYAML.\
-    \nPlease make sure to install pyyaml python package.\n")
+    \nPlease make sure to install pyyaml Python package.\n")
     sys.exit(1)
 
 __version__  = '1.0'
diff --git a/poky/documentation/standards.md b/poky/documentation/standards.md
index a2274f6..81aff5f 100644
--- a/poky/documentation/standards.md
+++ b/poky/documentation/standards.md
@@ -7,7 +7,29 @@
 
 ## Text standards
 
-This section has not been filled yet
+### Project names
+
+Project names should be capitalized in the same
+way they are on Wikipedia, in particular:
+
+* BitBake
+* OpenEmbedded
+
+There are exceptions in which such names can be used
+in lower case:
+
+* When referring to a package name
+* When referring to the corresponding command name
+* When used in a cross-reference title. Such
+  titles are usually in lower case.
+
+### File names
+
+File names should be quoted as in the below example:
+
+     ``conf/local.conf``
+
+Using "conf/local/conf" would be wrong.
 
 ## ReStructured Text Syntax standards
 
@@ -26,8 +48,14 @@
     .. image:: figures/user-configuration.png
        :align: center
 
-Depending on the size of the image, you may also shrink it
-to prevent it from filling the whole page width:
+A diagram with many details usually needs to use
+the whole page width to be readable on all media.
+In this case, the `:align:` directive is unnecessary:
+
+       :scale: 100%
+
+Conversely, you may also shrink some images to
+to prevent them from filling the whole page width:
 
        :scale: 50%
 
diff --git a/poky/documentation/test-manual/intro.rst b/poky/documentation/test-manual/intro.rst
index 9c1a93c..eb9ebe2 100644
--- a/poky/documentation/test-manual/intro.rst
+++ b/poky/documentation/test-manual/intro.rst
@@ -72,7 +72,7 @@
 .. note::
 
    The project uses Buildbot for historical reasons but also because
-   many of the project developers have knowledge of python. It is
+   many of the project developers have knowledge of Python. It is
    possible to use the outer layers from another Continuous Integration
    (CI) system such as
    `Jenkins <https://en.wikipedia.org/wiki/Jenkins_(software)>`__
@@ -83,6 +83,7 @@
 
 .. image:: figures/ab-test-cluster.png
    :align: center
+   :width: 70%
 
 Yocto Project Tests - Types of Testing Overview
 ===============================================
@@ -335,12 +336,12 @@
             self.assertEqual(str(val), "value_of_foo")
 
 In this example, a ``DataExpansions`` class of tests is created,
-derived from standard python unittest. The class has a common ``setUp``
+derived from standard Python unittest. The class has a common ``setUp``
 function which is shared by all the tests in the class. A simple test is
 then added to test that when a variable is expanded, the correct value
 is found.
 
-Bitbake selftests are straightforward python unittest. Refer to the
+BitBake selftests are straightforward Python unittest. Refer to the
 Python unittest documentation for additional information on writing
 these tests at: https://docs.python.org/3/library/unittest.html.
 
@@ -468,7 +469,7 @@
 
 In this example, if nativesdk-python3-core has been installed into the SDK, the code runs
 the python3 interpreter with a basic command to check it is working
-correctly. The test would only run if python3 is installed in the SDK.
+correctly. The test would only run if Python3 is installed in the SDK.
 
 ``oe-build-perf-test``
 ----------------------
diff --git a/poky/documentation/toaster-manual/intro.rst b/poky/documentation/toaster-manual/intro.rst
index 57e5b2b..a324744 100644
--- a/poky/documentation/toaster-manual/intro.rst
+++ b/poky/documentation/toaster-manual/intro.rst
@@ -92,6 +92,7 @@
 
 .. image:: figures/simple-configuration.png
    :align: center
+   :width: 70%
 
 Toaster as a hosted service is suited for multiple users developing
 across several build hosts. When Toaster is set up as a hosted service,
@@ -99,3 +100,4 @@
 
 .. image:: figures/hosted-service.png
    :align: center
+   :width: 50%
diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst
index 1e1a314..72a15b5 100644
--- a/poky/documentation/toaster-manual/setup-and-use.rst
+++ b/poky/documentation/toaster-manual/setup-and-use.rst
@@ -311,7 +311,7 @@
     migrations). The next line sets the Toaster root directory
     ``TOASTER_DIR`` and the location of the Toaster configuration file
     ``TOASTER_CONF``, which is relative to ``TOASTER_DIR``. The
-    ``TEMPLATECONF`` value reflects the contents of
+    :term:`TEMPLATECONF` value reflects the contents of
     ``poky/.templateconf``, and by default, should include the string
     "poky". For more information on the Toaster configuration file, see
     the ":ref:`toaster-manual/reference:Configuring Toaster`" section.
diff --git a/poky/documentation/toaster-manual/start.rst b/poky/documentation/toaster-manual/start.rst
index cab5d1f..2d64748 100644
--- a/poky/documentation/toaster-manual/start.rst
+++ b/poky/documentation/toaster-manual/start.rst
@@ -40,7 +40,7 @@
    $ pip3 install --user -r bitbake/toaster-requirements.txt
 
 The previous command installs the necessary Toaster modules into a local
-python 3 cache in your ``$HOME`` directory. The caches is actually
+Python 3 cache in your ``$HOME`` directory. The caches is actually
 located in ``$HOME/.local``. To see what packages have been installed
 into your ``$HOME`` directory, do the following::
 
diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst
index dec5617..46c5cf1 100644
--- a/poky/documentation/what-i-wish-id-known.rst
+++ b/poky/documentation/what-i-wish-id-known.rst
@@ -98,6 +98,7 @@
    be going wrong.
 
    .. image:: figures/yp-how-it-works-new-diagram.png
+      :width: 100%
 
 #. **Know that you can generate a dependency graph and learn how to do it:**
    A dependency graph shows dependencies between recipes, tasks, and targets.
@@ -179,7 +180,7 @@
    * understand devtool and how it simplifies your workflow
    * improve build speeds with shared downloads and shared state cache
    * generate and understand a dependency graph
-   * generate and understand bitbake environment
+   * generate and understand BitBake environment
    * build an Extensible SDK for applications development
 
 #. **Depending on what you primary interests are with the Yocto Project, you