diff options
author | Andrew Geissler <geissonator@yahoo.com> | 2020-10-16 18:22:50 +0300 |
---|---|---|
committer | Andrew Geissler <geissonator@yahoo.com> | 2020-10-19 20:45:27 +0300 |
commit | af5e4ef732faedf66c6dc1756432e9de2ac72988 (patch) | |
tree | 8f49154a7382b1beb2c3a2b50a6e7c632484fa25 /poky/documentation/ref-manual/ref-release-process.xml | |
parent | 36fe5df200a94e3ce82ba2dcad16c0a4127f6d46 (diff) | |
download | openbmc-af5e4ef732faedf66c6dc1756432e9de2ac72988.tar.xz |
poky: subtree update:b23aa6b753..ad30a6d470
Armin Kuster (1):
timezone: update to 2020b
Bruce Ashfield (7):
linux-yocto/5.4: fix kprobes build warning
linux-yocto/5.4: update to v5.4.67
linux-yocto/5.8: update to v5.8.11
linux-yocto/5.4: update to v5.4.68
linux-yocto/5.8: update to v5.8.12
linux-yocto/5.4: update to v5.4.69
linux-yocto/5.8: update to v5.8.13
Fabio Berton (1):
weston-init: Add environment file support for systemd unit file
Jon Mason (5):
armv8/tunes: Move TUNECONFLICTS
armv8/tunes: reference parent's TUNE_FEATURES
armv8/tunes: Add tunes for supported ARMv8a cores
armv8/tunes: Add tunes for supported ARMv8.2a cores
tune-cortexa32: fix cortexa32 tune
Joshua Watt (2):
classes/sanity: Bump minimum python version to 3.5
classes/waf: Add build and install arguments
Khem Raj (3):
systemd: Use ROOTPREFIX without suffixed slash in systemd.pc.in
musl: Update to master
strace: Fix value of IPPROTO_MAX
Martin Jansa (3):
base.bbclass: use os.path.normpath instead of just comparing WORKDIR and S as strings
mtd-utils: don't use trailing slash in S
base.bbclass: warn when there is trailing slash in S or B variables
Michael Thalmeier (1):
IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation
Naoki Hayama (3):
uninative: Fix typo in error message
local.conf.sample: Fix comment typo
local.conf.sample.extended: Fix comment typo
Naveen Saini (2):
linux-yocto: update genericx86* SRCREV for 5.4
linux-yocto: update genericx86* SRCREV for 5.8
Nicolas Dechesne (8):
bitbake: docs: ref-variables: add links to terms in glossary
bitbake: docs: sphinx: replace special quotes with double quotes
bitbake: docs: update README file after migrationg to Sphinx
bitbake: docs: sphinx: report errors when dependencies are not met
bitbake: sphinx: remove DocBook files
bitbake: sphinx: rename Makefile.sphinx
sphinx: remove DocBook files
sphinx: rename Makefile.sphinx
Peter Kjellerstedt (1):
tune-cortexa65.inc: Correct TUNE_FEATURES_tune-cortexa65
Quentin Schulz (4):
docs: ref-manual: ref-variables: fix one-letter pointer links in glossary
docs: ref-manual: ref-variables: fix alphabetical order in glossary
docs: ref-manual: ref-variables: add links to terms in glossary
bitbake: docs: static: theme_overrides.css: fix responsive design on <640px screens
Richard Purdie (25):
glibc: do_stash_locale must not delete files from ${D}
libtools-cross/shadow-sysroot: Use nopackages inherit
pseudo: Ignore mismatched inodes from the db
pseudo: Add support for ignoring paths from the pseudo DB
pseudo: Abort on mismatch patch
psuedo: Add tracking of linked files for fds
pseudo: Fix xattr segfault
pseudo: Add may unlink patch
pseudo: Add pathfix patch
base/bitbake.conf: Enable pseudo path filtering
wic: Handle new PSEUDO_IGNORE_PATHS variable
pseudo: Fix statx function usage
bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta
docs: Fix license CC-BY-2.0-UK -> CC-BY-SA-2.0-UK
abi_version,sanity: Tell users TMPDIR must be clean after pseudo changes
pseudo: Update to account for patches merged on branch
pseudo: Upgrade to include mkostemp64 wrapper
poky.conf: Drop OELAYOUT_ABI poking
bitbake: command: Ensure exceptions inheriting from BBHandledException are visible
bitbake: tinfoil: When sending commands we need to process events
scripts/oe-build-perf-report: Allow operation with no buildstats
oe-build-perf-report: Ensure correct data is shown for multiple branch options
skeleton/baremetal-helloworld: Fix trailing slash
oeqa/selftest/runtime_test: Exclude gpg directory from pseudo database
bitbake: process: Show command exceptions in the server log as well
Ross Burton (10):
bjam-native: don't do debug builds
coreutils: improve coreutils-ptest RDEPENDS
parted: improve ptest
devtool: remove unused variable
selftest: skip npm tests if nodejs-native isn't available
selftest: add test for recipes with patches in overrides
devtool: fix modify with patches in override directories
boost: build a standalone boost.build
boost: don't specify gcc version
boost: consolidate and update library list
Usama Arif (1):
kernel-fitimage: generate openssl RSA keys for signing fitimage
Victor Kamensky (2):
qemu: add 34Kf-64tlb fictitious cpu type
qemumips: use 34Kf-64tlb CPU emulation
Yann Dirson (1):
rngd: fix --debug to also filter syslog() calls
Yoann Congal (1):
bitbake-bblayers/create: Make the example recipe print its message
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I7139cb04b43f722a2118df5346a7a22a13c6a240
Diffstat (limited to 'poky/documentation/ref-manual/ref-release-process.xml')
-rw-r--r-- | poky/documentation/ref-manual/ref-release-process.xml | 256 |
1 files changed, 0 insertions, 256 deletions
diff --git a/poky/documentation/ref-manual/ref-release-process.xml b/poky/documentation/ref-manual/ref-release-process.xml deleted file mode 100644 index 87f530806..000000000 --- a/poky/documentation/ref-manual/ref-release-process.xml +++ /dev/null @@ -1,256 +0,0 @@ -<!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 ---> |