diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index ab71cbe..1d01456 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -665,7 +665,7 @@
 to the desired size, in bytes.
 
 See :oe_git:`devicetree.bbclass sources
-</openembedded-core/tree/meta/classes-recipe/devicetree.bbclass>` 
+</openembedded-core/tree/meta/classes-recipe/devicetree.bbclass>`
 for further variables controlling this class.
 
 Here is an excerpt of an example ``recipes-kernel/linux/devicetree-acme.bb``
@@ -939,6 +939,20 @@
 
 See the associated :term:`GO_WORKDIR` variable.
 
+.. _ref-classes-go-vendor:
+
+``go-vendor``
+=============
+
+The :ref:`ref-classes-go-vendor` class implements support for offline builds,
+also known as Go vendoring. In such a scenario, the module dependencias are
+downloaded during the :ref:`ref-tasks-fetch` task rather than when modules are
+imported, thus being coherent with Yocto's concept of fetching every source
+beforehand.
+
+The dependencies are unpacked into the modules' ``vendor`` directory, where a
+manifest file is generated.
+
 .. _ref-classes-gobject-introspection:
 
 ``gobject-introspection``
@@ -3270,7 +3284,7 @@
 -  :term:`UBOOT_FIT_KEY_REQ_ARGS`: ``openssl req`` arguments.
 -  :term:`UBOOT_FIT_SIGN_ALG`: signature algorithm for the FIT image.
 -  :term:`UBOOT_FIT_SIGN_NUMBITS`: size of the private key for FIT image
-   signing.                                                  
+   signing.
 -  :term:`UBOOT_FIT_KEY_SIGN_PKCS`: algorithm for the public key certificate
    for FIT image signing.
 -  :term:`UBOOT_FITIMAGE_ENABLE`: enable the generation of a U-Boot FIT image.
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index 8e54ac8..4eaaca9 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -66,6 +66,9 @@
 -  :yocto_lists:`/g/yocto` --- general Yocto Project
    discussion mailing list.
 
+-  :yocto_lists:`/g/yocto-patches` --- patch contribution mailing list for Yocto
+   Project-related layers which do not have their own mailing list.
+
 -  :oe_lists:`/g/openembedded-core` --- discussion mailing
    list about OpenEmbedded-Core (the core metadata).
 
diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index c28cd7a..2e4b234 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -358,7 +358,7 @@
 ``do_populate_sdk_ext``
 -----------------------
 
-Creates the file and directory structure for an installable extensible 
+Creates the file and directory structure for an installable extensible
 SDK (eSDK). See the ":ref:`overview-manual/concepts:sdk generation`"
 section in the Yocto Project Overview and Concepts Manual for more
 information.
diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst
index ad9c46c..b18c418 100644
--- a/poky/documentation/ref-manual/terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -228,23 +228,23 @@
 
          As far as bootloaders are concerned, :term:`Initramfs` and "initrd"
          images are still copied to RAM in the same way. That's why most
-	 most bootloaders refer to :term:`Initramfs` images as "initrd"
-	 or "init RAM disk".
+         most bootloaders refer to :term:`Initramfs` images as "initrd"
+         or "init RAM disk".
 
       This kind of mechanism is typically used for two reasons:
 
       -  For booting the same kernel binary on multiple systems requiring
          different device drivers. The :term:`Initramfs` image is then customized
-	 for each type of system, to include the specific kernel modules
+         for each type of system, to include the specific kernel modules
          necessary to access the final root filesystem. This technique
-	 is used on all GNU / Linux distributions for desktops and servers.
+         is used on all GNU / Linux distributions for desktops and servers.
 
       -  For booting faster. As the root filesystem is extracted into RAM,
          accessing the first user-space applications is very fast, compared
          to having to initialize a block device, to access multiple blocks
          from it, and to go through a filesystem having its own overhead.
          For example, this allows to display a splashscreen very early,
-	 and to later take care of mounting the final root filesystem and
+         and to later take care of mounting the final root filesystem and
          loading less time-critical kernel drivers.
 
       This cpio archive can either be loaded to RAM by the bootloader,
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 435481c..0dc881e 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -561,6 +561,10 @@
    :term:`BB_INVALIDCONF`
       See :term:`bitbake:BB_INVALIDCONF` in the BitBake manual.
 
+   :term:`BB_LOADFACTOR_MAX`
+      The system load threshold above which BitBake will stop runnig extra
+      tasks.
+
    :term:`BB_LOGCONFIG`
       See :term:`bitbake:BB_LOGCONFIG` in the BitBake manual.
 
@@ -1688,6 +1692,11 @@
       The list of package names (:term:`PN`) for which
       CVEs (Common Vulnerabilities and Exposures) are ignored.
 
+   :term:`CVE_DB_INCR_UPDATE_AGE_THRES`
+      Specifies the maximum age of the CVE database in seconds for an
+      incremental update (instead of a full-download). Use "0" to force a
+      full-download.
+
    :term:`CVE_DB_UPDATE_INTERVAL`
       Specifies the CVE database update interval in seconds, as used by
       ``cve-update-db-native``. The default value is "86400" i.e. once a day
@@ -2330,6 +2339,12 @@
       See the :ref:`ref-classes-systemd-boot` and :ref:`ref-classes-image-live`
       classes for more information.
 
+   :term:`EFI_UKI_DIR`
+      The primary place for the UKI image inside the EFI System Partition.
+
+   :term:`EFI_UKI_PATH`
+      The path for the UKI image inside the root filesystem.
+
    :term:`ENABLE_BINARY_LOCALE_GENERATION`
       Variable that controls which locales for ``glibc`` are generated
       during the build (useful if the target device has 64Mbytes of RAM or
@@ -2983,18 +2998,18 @@
 
    :term:`FIT_ADDRESS_CELLS`
       Specifies the value of the ``#address-cells`` value for the
-      description of the FIT image.  
+      description of the FIT image.
 
       The default value is set to "1" by the :ref:`ref-classes-kernel-fitimage`
-      class, which corresponds to 32 bit addresses. 
+      class, which corresponds to 32 bit addresses.
 
       For platforms that need to set 64 bit addresses, for example in
       :term:`UBOOT_LOADADDRESS` and :term:`UBOOT_ENTRYPOINT`, you need to
-      set this value to "2", as two 32 bit values (cells) will be needed 
+      set this value to "2", as two 32 bit values (cells) will be needed
       to represent such addresses.
 
       Here is an example setting "0x400000000" as a load address::
-    
+
          FIT_ADDRESS_CELLS = "2"
          UBOOT_LOADADDRESS= "0x04 0x00000000"
 
@@ -3971,15 +3986,15 @@
       Specifies a space-separated list of license names (as they would
       appear in :term:`LICENSE`) that should be excluded
       from the build (if set globally), or from an image (if set locally
-      in an image recipe). 
+      in an image recipe).
 
       When the variable is set globally, recipes that provide no alternatives to listed
       incompatible licenses are not built. Packages that are individually
-      licensed with the specified incompatible licenses will be deleted. 
+      licensed with the specified incompatible licenses will be deleted.
       Most of the time this does not allow a feasible build (because it becomes impossible
       to satisfy build time dependencies), so the recommended way to
       implement license restrictions is to set the variable in specific
-      image recipes where the restrictions must apply. That way there 
+      image recipes where the restrictions must apply. That way there
       are no build time restrictions, but the license check is still
       performed when the image's filesystem is assembled from packages.
 
@@ -4495,12 +4510,12 @@
       When kernel configuration fragments are missing for some
       :term:`KERNEL_FEATURES` specified by layers or BSPs,
       building and configuring the kernel stops with an error.
-    
+
       You can turn these errors into warnings by setting the
       following in ``conf/local.conf``::
 
          KERNEL_DANGLING_FEATURES_WARN_ONLY = "1"
-    
+
       You will still be warned that runtime issues may occur,
       but at least the kernel configuration and build process will
       be allowed to continue.
@@ -5666,6 +5681,9 @@
       default by setting the variable in a custom distribution
       configuration file.
 
+   :term:`OPKG_MAKE_INDEX_EXTRA_PARAMS`
+      Specifies extra parameters for the ``opkg-make-index`` command.
+
    :term:`OVERLAYFS_ETC_DEVICE`
       When the :ref:`ref-classes-overlayfs-etc` class is
       inherited, specifies the device to be mounted for the read/write
@@ -7147,6 +7165,9 @@
       :term:`IMAGE_ROOTFS` variable for more
       information.
 
+   :term:`RPMBUILD_EXTRA_PARAMS`
+      Specifies extra user-defined parameters for the ``rpmbuild`` command.
+
    :term:`RPROVIDES`
       A list of package name aliases that a package also provides. These
       aliases are useful for satisfying runtime dependencies of other
@@ -7868,7 +7889,7 @@
       This option allows to associate `SPDX annotations
       <https://spdx.github.io/spdx-spec/v2.3/annotations/>`__ to a recipe,
       using the values of variables in the recipe::
-        
+
          ANNOTATION1 = "First annotation for recipe"
          ANNOTATION2 = "Second annotation for recipe"
          SPDX_CUSTOM_ANNOTATION_VARS = "ANNOTATION1 ANNOTATION2"
@@ -7991,7 +8012,7 @@
       The name of keys used by the :ref:`ref-classes-kernel-fitimage` class
       for signing U-Boot FIT image stored in the :term:`SPL_SIGN_KEYDIR`
       directory. If we have for example a ``dev.key`` key and a ``dev.crt``
-      certificate stored in the :term:`SPL_SIGN_KEYDIR` directory, you will 
+      certificate stored in the :term:`SPL_SIGN_KEYDIR` directory, you will
       have to set :term:`SPL_SIGN_KEYNAME` to ``dev``.
 
    :term:`SPLASH`
@@ -8028,7 +8049,7 @@
 
           EXTRA_OECONF += "--disable-startup-msg --enable-img-fullscreen"
 
-      For information on append files, see the                                                                            
+      For information on append files, see the
       ":ref:`dev-manual/layers:appending other layers metadata with your layer`"
       section.
 
@@ -9442,10 +9463,10 @@
 
    :term:`UBOOT_FIT_ADDRESS_CELLS`
       Specifies the value of the ``#address-cells`` value for the
-      description of the U-Boot FIT image.  
+      description of the U-Boot FIT image.
 
       The default value is set to "1" by the :ref:`ref-classes-uboot-sign`
-      class, which corresponds to 32 bit addresses. 
+      class, which corresponds to 32 bit addresses.
 
       For platforms that need to set 64 bit addresses in
       :term:`UBOOT_LOADADDRESS` and :term:`UBOOT_ENTRYPOINT`, you need to
@@ -9453,7 +9474,7 @@
       to represent such addresses.
 
       Here is an example setting "0x400000000" as a load address::
-    
+
          UBOOT_FIT_ADDRESS_CELLS = "2"
          UBOOT_LOADADDRESS= "0x04 0x00000000"
 
@@ -9516,7 +9537,7 @@
          UBOOT_FITIMAGE_ENABLE = "1"
 
       See the :ref:`ref-classes-uboot-sign` class for details.
-      
+
    :term:`UBOOT_LOADADDRESS`
       Specifies the load address for the U-Boot image. During U-Boot image
       creation, the :term:`UBOOT_LOADADDRESS` variable is passed as a