poky: subtree update:0ac99625bf..796be0593a
Alexander Kanavin (31):
netbase: upgrade 6.1 -> 6.2
meson: upgrade 0.55.1 -> 0.56.0
vulkan-samples: update to latest revision
libcap: update 2.44 -> 2.45
bind: upgrade 9.16.7 -> 9.16.9
quota: upgrade 4.05 -> 4.06
pango: upgrade 1.46.2 -> 1.48.0
elfutils: upgrade 0.181 -> 0.182
ifupdown: upgrade 0.8.35 -> 0.8.36
createrepo-c: upgrade 0.16.1 -> 0.16.2
acpica: upgrade 20200925 -> 20201113
grep: upgrade 3.5 -> 3.6
man-pages: upgrade 5.08 -> 5.09
stress-ng: upgrade 0.11.23 -> 0.11.24
libhandy: upgrade 1.0.1 -> 1.0.2
piglit: upgrade to latest revision
xkbcomp: upgrade 1.4.3 -> 1.4.4
lz4: upgrade 1.9.2 -> 1.9.3
bison: upgrade 3.7.3 -> 3.7.4
python3-setuptools-scm: fix upstream version check
cantarell-fonts: update 0.0.25 -> 0.201
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
piglit: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
kea: fix reproducibility
poky.conf: do not write current date into distro version, use git hash instead
Andrej Valek (1):
kernel-dummy: fix executing unexpected tasks
Anuj Mittal (1):
releases.rst: add gatesgarth to current releases
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Chandana kalluri (1):
populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg
Changqing Li (1):
buildtools-tarball: add wic dependency into extended buildtools
Diego Sueiro (2):
modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
initscripts: Change execution order between checkroot and modutils
Dmitry Baryshkov (2):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
Fabio Berton (1):
mesa: Update 20.2.1 -> 20.2.4
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Jack Mitchell (3):
Revert "connman: set service to conflict with systemd-networkd"
systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
systemd-conf: match ethernet interfaces by type rather than globbing
Joshua Watt (2):
bitbake: hashserv: client: Fix AF_UNIX path length limits
bitbake: hashserv: Fix broken AF_UNIX path length limit
Kai Kang (2):
systemd-systemctl-native: capable to call without argument
systemd.bbclass: update command to check systemctl available
Kevin Hao (1):
tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
Li Wang (2):
qemu: CVE-2020-29129 CVE-2020-29130
qemu: CVE-2020-25624
Luca Boccassi (1):
dbus: move messagebus user to dbus-common package
Michael Halstead (1):
releases: conf: add link to 3.1.4, update to include 3.1.4
Nicolas Dechesne (19):
sphinx: add .vscode in .gitignore
{dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
sphinx: replace bitbake labels with references to corresponding title
brief-yoctoprojectqs: replace labels with references to section title
dev-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
sdk-manual: replace labels with references to section title
overview-manual: remove unused labels
dev-manual: remove unused labels
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
Paul Barker (5):
documentation: Simplify yocto_wiki links
documentation: Simplify yocto_git links
ref-manual: Simplify oe_git links
poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
poky.conf: Drop fedora-30 from tested distros
Peter Kjellerstedt (2):
pseudo: Simplify pseudo_client_ignore_path_chroot()
bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Richard Purdie (8):
lz4: Use the new branch naming from upstream
Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
build-appliance-image: Update to master head revision
bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
build-appliance-image: Update to master head revision
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
poky: Set SDK_VERSION explicitly
build-appliance-image: Update to master head revision
Ross Burton (9):
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
image_types: remove obsolete tar comment
image_types: sort tarball file listings
package_manager/ipk: neaten OPKGLIBDIR logic
ldconfig-native: don't write auxiliary cache
package_manager/ipk: improve remove_packaging_data
oeqa/selftest/containerimage: update for improved cleanup
coreutils: add SUSE-specific issues to CVE whitelist
bitbake: msg: use safe YAML loader
Sinan Kaya (1):
poky-tiny: enable section removal
Tomasz Dziendzielski (1):
pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (3):
libinput: upgrade 1.16.3 -> 1.16.4
lighttpd: upgrade 1.4.55 -> 1.4.56
sysstat: upgrade 12.4.0 -> 12.4.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51
diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst
new file mode 100644
index 0000000..d8d3622
--- /dev/null
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -0,0 +1,191 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+*****************************************************
+Yocto Project Releases and the Stable Release Process
+*****************************************************
+
+The Yocto Project release process is predictable and consists of both
+major and minor (point) releases. This brief chapter provides
+information on how releases are named, their life cycle, and their
+stability.
+
+Major and Minor Release Cadence
+===============================
+
+The Yocto Project delivers major releases (e.g. DISTRO) using a six
+month cadence roughly timed each April and October of the year.
+Following are examples of some major YP releases with their codenames
+also shown. See the "`Major Release
+Codenames <#major-release-codenames>`__" section for information on
+codenames used with major releases.
+
+ - 2.2 (Morty)
+ - 2.1 (Krogoth)
+ - 2.0 (Jethro)
+
+While the cadence is never perfect, this timescale facilitates
+regular releases that have strong QA cycles while not overwhelming users
+with too many new releases. The cadence is predictable and avoids many
+major holidays in various geographies.
+
+The Yocto project delivers minor (point) releases on an unscheduled
+basis and are usually driven by the accumulation of enough significant
+fixes or enhancements to the associated major release. Following are
+some example past point releases:
+
+ - 2.1.1
+ - 2.1.2
+ - 2.2.1
+
+The point release
+indicates a point in the major release branch where a full QA cycle and
+release process validates the content of the new branch.
+
+.. note::
+
+ Realize that there can be patches merged onto the stable release
+ branches as and when they become available.
+
+Major Release Codenames
+=======================
+
+Each major release receives a codename that identifies the release in
+the :ref:`overview-manual/development-environment:yocto project source repositories`.
+The concept is that branches of :term:`Metadata` with the same
+codename are likely to be compatible and thus work together.
+
+.. note::
+
+ Codenames are associated with major releases because a Yocto Project
+ release number (e.g. DISTRO) could conflict with a given layer or
+ company versioning scheme. Codenames are unique, interesting, and
+ easily identifiable.
+
+Releases are given a nominal release version as well but the codename is
+used in repositories for this reason. You can find information on Yocto
+Project releases and codenames at
+:yocto_wiki:`/Releases`.
+
+Stable Release Process
+======================
+
+Once released, the release enters the stable release process at which
+time a person is assigned as the maintainer for that stable release.
+This maintainer monitors activity for the release by investigating and
+handling nominated patches and backport activity. Only fixes and
+enhancements that have first been applied on the "master" branch (i.e.
+the current, in-development branch) are considered for backporting to a
+stable release.
+
+.. note::
+
+ The current Yocto Project policy regarding backporting is to consider
+ bug fixes and security fixes only. Policy dictates that features are
+ not backported to a stable release. This policy means generic recipe
+ version upgrades are unlikely to be accepted for backporting. The
+ exception to this policy occurs when a strong reason exists such as
+ the fix happens to also be the preferred upstream approach.
+
+Stable release branches have strong maintenance for about a year after
+their initial release. Should significant issues be found for any
+release regardless of its age, fixes could be backported to older
+releases. For issues that are not backported given an older release,
+Community LTS trees and branches exist where community members share
+patches for older releases. However, these types of patches do not go
+through the same release process as do point releases. You can find more
+information about stable branch maintenance at
+:yocto_wiki:`/Stable_branch_maintenance`.
+
+Testing and Quality Assurance
+=============================
+
+Part of the Yocto Project development and release process is quality
+assurance through the execution of test strategies. Test strategies
+provide the Yocto Project team a way to ensure a release is validated.
+Additionally, because the test strategies are visible to you as a
+developer, you can validate your projects. This section overviews the
+available test infrastructure used in the Yocto Project. For information
+on how to run available tests on your projects, see the
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
+section in the Yocto Project Development Tasks Manual.
+
+The QA/testing infrastructure is woven into the project to the point
+where core developers take some of it for granted. The infrastructure
+consists of the following pieces:
+
+- ``bitbake-selftest``: A standalone command that runs unit tests on
+ key pieces of BitBake and its fetchers.
+
+- :ref:`sanity.bbclass <ref-classes-sanity>`: This automatically
+ included class checks the build environment for missing tools (e.g.
+ ``gcc``) or common misconfigurations such as
+ :term:`MACHINE` set incorrectly.
+
+- :ref:`insane.bbclass <ref-classes-insane>`: This class checks the
+ generated output from builds for sanity. For example, if building for
+ an ARM target, did the build produce ARM binaries. If, for example,
+ the build produced PPC binaries then there is a problem.
+
+- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
+ performs runtime testing of images after they are built. The tests
+ are usually used with :doc:`QEMU </dev-manual/qemu>`
+ to boot the images and check the combined runtime result boot
+ operation and functions. However, the test can also use the IP
+ address of a machine to test.
+
+- :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`:
+ Runs tests against packages produced during the build for a given
+ piece of software. The test allows the packages to be be run within a
+ target image.
+
+- ``oe-selftest``: Tests combination BitBake invocations. These tests
+ operate outside the OpenEmbedded build system itself. The
+ ``oe-selftest`` can run all tests by default or can run selected
+ tests or test suites.
+
+ .. note::
+
+ Running ``oe-selftest`` requires host packages beyond the "Essential"
+ grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host`
+ section for more information.
+
+Originally, much of this testing was done manually. However, significant
+effort has been made to automate the tests so that more people can use
+them and the Yocto Project development team can run them faster and more
+efficiently.
+
+The Yocto Project's main Autobuilder (&YOCTO_AB_URL;)
+publicly tests each Yocto Project release's code in the
+:term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
+occurs for both the current state of the "master" branch and also for
+submitted patches. Testing for submitted patches usually occurs in the
+"ross/mut" branch in the ``poky-contrib`` repository (i.e. the
+master-under-test branch) or in the "master-next" branch in the ``poky``
+repository.
+
+.. note::
+
+ You can find all these branches in the Yocto Project
+ Source Repositories
+ .
+
+Testing within these public branches ensures in a publicly visible way
+that all of the main supposed architectures and recipes in OE-Core
+successfully build and behave properly.
+
+Various features such as ``multilib``, sub architectures (e.g. ``x32``,
+``poky-tiny``, ``musl``, ``no-x11`` and and so forth),
+``bitbake-selftest``, and ``oe-selftest`` are tested as part of the QA
+process of a release. Complete testing and validation for a release
+takes the Autobuilder workers several hours.
+
+.. note::
+
+ The Autobuilder workers are non-homogeneous, which means regular
+ testing across a variety of Linux distributions occurs. The
+ Autobuilder is limited to only testing QEMU-based setups and not real
+ hardware.
+
+Finally, in addition to the Autobuilder's tests, the Yocto Project QA
+team also performs testing on a variety of platforms, which includes
+actual hardware, to ensure expected results.