From c643a4749c436baeb6943fe960f77a48deaef8e5 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Tue, 23 Mar 2021 17:58:45 +0100 Subject: manuals: Spellcheck and capitalization fixes - Spelling fixes found using Emacs' spelling checker configured for US English - Fixes for some capitalization issues, especially some project names (QEMU, openSUSE, BusyBox), that were not consistently used with the same capitalization anyway. - A few whitespace fixes too (From yocto-docs rev: 05d69f17490dcc4933dcd85e57d9db53b912084a) Signed-off-by: Michael Opdenacker Reviewed-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- documentation/test-manual/intro.rst | 10 +++++----- documentation/test-manual/test-process.rst | 4 ++-- documentation/test-manual/understand-autobuilder.rst | 12 ++++++------ 3 files changed, 13 insertions(+), 13 deletions(-) (limited to 'documentation/test-manual') diff --git a/documentation/test-manual/intro.rst b/documentation/test-manual/intro.rst index 81c24a8c3f..101d283665 100644 --- a/documentation/test-manual/intro.rst +++ b/documentation/test-manual/intro.rst @@ -26,7 +26,7 @@ engineers: - *yocto-autobuilder2:* This :yocto_git:`README.md ` - is the main README which detials how to set up the Yocto Project + is the main README which details how to set up the Yocto Project Autobuilder. The ``yocto-autobuilder2`` repository represents the Yocto Project's console UI plugin to Buildbot and the configuration necessary to configure Buildbot to perform the testing the project @@ -88,7 +88,7 @@ Yocto Project Tests - Types of Testing Overview =============================================== The Autobuilder tests different elements of the project by using -thefollowing types of tests: +the following types of tests: - *Build Testing:* Tests whether specific configurations build by varying :term:`MACHINE`, @@ -124,7 +124,7 @@ thefollowing types of tests: The tests utilize the ``testsdkext`` class and the ``do_testsdkext`` task. - *Feature Testing:* Various scenario-based tests are run through the - :ref:`OpenEmbedded Self test (oe-selftest) `. We test oe-selftest on each of the main distrubutions + :ref:`OpenEmbedded Self test (oe-selftest) `. We test oe-selftest on each of the main distributions we support. - *Image Testing:* Image tests initiated through the following command:: @@ -474,7 +474,7 @@ correctly. The test would only run if python3 is installed in the SDK. ---------------------- The performance tests usually measure how long operations take and the -resource utilisation as that happens. An example from +resource utilization as that happens. An example from ``meta/lib/oeqa/buildperf/test_basic.py`` contains the following:: class Test3(BuildPerfTestCase): @@ -524,5 +524,5 @@ This is particularly true for oe-selftests since these can run in parallel and changing metadata leads to changing checksums, which confuses BitBake while running in parallel. If this is necessary, copy layers to a temporary location and modify them. Some tests need to -change metadata, such as the devtool tests. To prevent the metadate from +change metadata, such as the devtool tests. To protect the metadata from changes, set up temporary copies of that data first. diff --git a/documentation/test-manual/test-process.rst b/documentation/test-manual/test-process.rst index 8a5e29d922..508ead5fad 100644 --- a/documentation/test-manual/test-process.rst +++ b/documentation/test-manual/test-process.rst @@ -59,13 +59,13 @@ 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 +milestone releases (usually four) with the final one being stabilization 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 <#test-daily-devel>`__, 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, +configured to generate and publish artifacts and the milestone number, version, release candidate number and other information is entered. The box to "generate an email to QA"is also checked. diff --git a/documentation/test-manual/understand-autobuilder.rst b/documentation/test-manual/understand-autobuilder.rst index 199cc97a85..2d9d6735a9 100644 --- a/documentation/test-manual/understand-autobuilder.rst +++ b/documentation/test-manual/understand-autobuilder.rst @@ -9,14 +9,14 @@ Execution Flow within the Autobuilder The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and it makes sense to follow the process through the system -starting there. This is best visualised from the Autobuilder Console +starting there. This is best visualized from the Autobuilder Console view (:yocto_ab:`/typhoon/#/console`). Each item along the top of that view represents some "target build" and these targets are all run in parallel. The 'full' build will trigger the majority of them, the "quick" build will trigger some subset of them. The Autobuilder effectively runs whichever configuration is defined for -each of those targets on a seperate buildbot worker. To understand the +each of those targets on a separate buildbot worker. To understand the configuration, you need to look at the entry on ``config.json`` file within the ``yocto-autobuilder-helper`` repository. The targets are defined in the ‘overrides' section, a quick example could be qemux86-64 @@ -64,10 +64,10 @@ While not every detail of this is covered here, you can see how the template mechanism allows quite complex configurations to be built up yet allows duplication and repetition to be kept to a minimum. -The different build targets are designed to allow for parallelisation, +The different build targets are designed to allow for parallelization, so different machines are usually built in parallel, operations using the same machine and metadata are built sequentially, with the aim of -trying to optimise build efficiency as much as possible. +trying to optimize build efficiency as much as possible. The ``config.json`` file is processed by the scripts in the Helper repository in the ``scripts`` directory. The following section details @@ -164,7 +164,7 @@ Autobuilder Worker Janitor This is a process running on each Worker that performs two basic operations, including background file deletion at IO idle (see :ref:`test-manual/understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and -maintainenance of a cache of cloned repositories to improve the speed +maintenance of a cache of cloned repositories to improve the speed the system can checkout repositories. Shared DL_DIR @@ -250,7 +250,7 @@ Deploying Yocto Autobuilder =========================== The most up to date information about how to setup and deploy your own -Autbuilder can be found in README.md in the ``yocto-autobuilder2`` +Autobuilder can be found in README.md in the ``yocto-autobuilder2`` repository. We hope that people can use the ``yocto-autobuilder2`` code directly but -- cgit v1.2.3-54-g00ecf