Revert "poky: subtree update:b23aa6b753..ad30a6d470"
This reverts commit af5e4ef732faedf66c6dc1756432e9de2ac72988.
This commit introduced openbmc/openbmc#3720 and no solution has been
forthcoming. Revert until we can get to the bottom of this.
Change-Id: I2fb0d81eb26cf3dadb2f2abdd1a1bb7a95eaf03c
diff --git a/poky/documentation/ref-manual/ref-release-process.xml b/poky/documentation/ref-manual/ref-release-process.xml
new file mode 100644
index 0000000..87f5308
--- /dev/null
+++ b/poky/documentation/ref-manual/ref-release-process.xml
@@ -0,0 +1,256 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
+
+<chapter id='ref-release-process'>
+<title>Yocto Project Releases and the Stable Release Process</title>
+
+<para>
+ 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.
+</para>
+
+<section id='major-and-minor-release-cadence'>
+ <title>Major and Minor Release Cadence</title>
+
+ <para>
+ 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
+ "<link linkend='major-release-codenames'>Major Release Codenames</link>"
+ section for information on codenames used with major releases.
+ <literallayout class='monospaced'>
+ 2.2 (Morty)
+ 2.1 (Krogoth)
+ 2.0 (Jethro)
+ </literallayout>
+ 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.
+ </para>
+
+ <para>
+ 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:
+ <literallayout class='monospaced'>
+ 2.1.1
+ 2.1.2
+ 2.2.1
+ </literallayout>
+ 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.
+ </note>
+ </para>
+</section>
+
+<section id='major-release-codenames'>
+ <title>Major Release Codenames</title>
+
+ <para>
+ Each major release receives a codename that identifies the release in
+ the
+ <ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>.
+ The concept is that branches of
+ <link linkend='metadata'>Metadata</link>
+ 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.
+ </note>
+ 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
+ <ulink url='https://wiki.yoctoproject.org/wiki/Releases'></ulink>.
+ </para>
+</section>
+
+<section id='stable-release-process'>
+ <title>Stable Release Process</title>
+
+ <para>
+ 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.
+ </note>
+ </para>
+
+ <para>
+ 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
+ <ulink url='https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance'></ulink>.
+ </para>
+</section>
+
+<section id='testing-and-quality-assurance'>
+ <title>Testing and Quality Assurance</title>
+
+ <para>
+ 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
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para>
+
+ <para>
+ 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:
+ <itemizedlist>
+ <listitem><para>
+ <filename>bitbake-selftest</filename>:
+ A standalone command that runs unit tests on key pieces of
+ BitBake and its fetchers.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='ref-classes-sanity'><filename>sanity.bbclass</filename></link>:
+ This automatically included class checks the build environment
+ for missing tools (e.g. <filename>gcc</filename>) or common
+ misconfigurations such as
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ set incorrectly.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>:
+ 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.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='ref-classes-testimage*'><filename>testimage.bbclass</filename></link>:
+ This class performs runtime testing of images after they are
+ built.
+ The tests are usually used with
+ <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>QEMU</ulink>
+ 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.
+ </para></listitem>
+ <listitem><para>
+ <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'><filename>ptest</filename></ulink>:
+ 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.
+ </para></listitem>
+ <listitem><para>
+ <filename>oe-selftest</filename>:
+ Tests combination BitBake invocations.
+ These tests operate outside the OpenEmbedded build system
+ itself.
+ The <filename>oe-selftest</filename> can run all tests by
+ default or can run selected tests or test suites.
+ <note>
+ Running <filename>oe-selftest</filename> requires
+ host packages beyond the "Essential" grouping.
+ See the
+ "<link linkend='required-packages-for-the-build-host'>Required Packages for the Build Host</link>"
+ section for more information.
+ </note>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ The Yocto Project's main Autobuilder
+ (<filename>autobuilder.yoctoproject.org</filename>) publicly tests
+ each Yocto Project release's code in the
+ <link linkend='oe-core'>OE-Core</link>, 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 <filename>poky-contrib</filename> repository
+ (i.e. the master-under-test branch) or in the "master-next" branch
+ in the <filename>poky</filename> repository.
+ <note>
+ You can find all these branches in the Yocto Project
+ <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>.
+ </note>
+ 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.
+ </para>
+
+ <para>
+ Various features such as <filename>multilib</filename>, sub
+ architectures (e.g. <filename>x32</filename>,
+ <filename>poky-tiny</filename>, <filename>musl</filename>,
+ <filename>no-x11</filename> and and so forth),
+ <filename>bitbake-selftest</filename>, and
+ <filename>oe-selftest</filename> 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.
+ </note>
+ </para>
+
+ <para>
+ 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.
+ </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->