From af5e4ef732faedf66c6dc1756432e9de2ac72988 Mon Sep 17 00:00:00 2001 From: Andrew Geissler Date: Fri, 16 Oct 2020 10:22:50 -0500 Subject: 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 Change-Id: I7139cb04b43f722a2118df5346a7a22a13c6a240 --- .../test-manual/test-manual-test-process.xml | 110 --------------------- 1 file changed, 110 deletions(-) delete mode 100644 poky/documentation/test-manual/test-manual-test-process.xml (limited to 'poky/documentation/test-manual/test-manual-test-process.xml') diff --git a/poky/documentation/test-manual/test-manual-test-process.xml b/poky/documentation/test-manual/test-manual-test-process.xml deleted file mode 100644 index 6e2157c62..000000000 --- a/poky/documentation/test-manual/test-manual-test-process.xml +++ /dev/null @@ -1,110 +0,0 @@ - %poky; ] > - - - - -Project Testing and Release Process -
- Day to Day Development - - This section details how the project tests changes, through automation on the - Autobuilder or with the assistance of QA teams, through to making releases. - - The project aims to test changes against our test matrix before those changes are - merged into the master branch. As such, changes are queued up in batches either in the - master-next branch in the main trees, or in user trees such as - ross/mut in poky-contrib (Ross Burton - helps review and test patches and this is his testing tree). - We have two broad categories of test builds, including "full" and "quick". On the - Autobuilder, these can be seen as "a-quick" and "a-full", simply for ease of sorting in - the UI. Use our Autobuilder console view to see where me manage most test-related items, - available at: https://autobuilder.yoctoproject.org/typhoon/#/console. - Builds are triggered manually when the test branches are ready. The builds are - monitored by the SWAT team. For additional information, see https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team. If - successful, the changes would usually be merged to the master - branch. If not successful, someone would respond to the changes on the mailing list - explaining that there was a failure in testing. The choice of quick or full would depend - on the type of changes and the speed with which the result was required. - The Autobuilder does build the master branch once daily for - several reasons, in particular, to ensure the current master branch - does build, but also to keep yocto-testresults (http://git.yoctoproject.org/cgit.cgi/yocto-testresults/), buildhistory - (http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/), - and our sstate up to date. On the weekend, there is a master-next build instead to - ensure the test results are updated for the less frequently run targets. - Performance builds (buildperf-* targets in the console) are triggered separately every - six hours and automatically push their results to the buildstats repository at: http://git.yoctoproject.org/cgit.cgi/yocto-buildstats/. - The 'quick' targets have been selected to be the ones which catch the most failures or - give the most valuable data. We run 'fast' ptests in this case for example but not the - ones which take a long time. The quick target doesn't include *-lsb builds for all - architectures, some world builds and doesn't trigger performance tests or ltp testing. - The full build includes all these things and is slower but more comprehensive. -
- -
- Release Builds - - The project typically has two major releases a year with a six month cadence in April - and October. Between these there would be a number of milestone releases (usually four) - with the final one being stablization only along with point releases of our stable - branches. - The build and release process for these project releases is similar to that in Day to Day Development, in that the a-full target - of the Autobuilder is used but in addition the form is configured to generate and - publish artefacts and the milestone number, version, release candidate number and other - information is entered. The box to "generate an email to QA"is also checked. - When the build completes, an email is sent out using the send-qa-email script in the - yocto-autobuilder-helper repository to the list of people - configured for that release. Release builds are placed into a directory in https://autobuilder.yocto.io/pub/releases on the Autobuilder which - is included in the email. The process from here is more manual and control is - effectively passed to release engineering. The next steps include: - - QA teams respond to the email saying which tests they plan to run and when - the results will be available. - - - QA teams run their tests and share their results in the yocto- - testresults-contrib repository, along with a summary of their findings. - - - - Release engineering prepare the release as per their process. - - - Test results from the QA teams are included into the release in separate - directories and also uploaded to the yocto-testresults repository alongside - the other test results for the given revision. - - - The QA report in the final release is regenerated using resulttool to - include the new test results and the test summaries from the teams (as - headers to the generated report). - - - The release is checked against the release checklist and release readiness - criteria. - - - A final decision on whether to release is made by the YP TSC who have - final oversight on release readiness. - - -
- - - - - - - - - - -- cgit v1.2.3