make the documentation a bit more inclusive

Except the name of variables which can't be changed only in the
documentation for obvious reasons and workflow or developement
explanations around the use of the "master" branch which cannot be
replaced with "development" branch instead, most of the non-inclusive
words that appear in https://inclusivenaming.org/word-lists/tier-1/
should have been replaced in this patch.

(From yocto-docs rev: 2755f35060084f7af356091de9dc144f85530fe2)

Signed-off-by: Quentin Schulz <foss+yocto@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz
2021-12-06 16:04:01 +01:00
committed by Richard Purdie
parent 99474e0d68
commit e71983bc7d
14 changed files with 151 additions and 159 deletions

View File

@@ -763,7 +763,7 @@ Organizing Your Source
======================
Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux
kernel sources that have only a single branch - "master". This type of
kernel sources that have only a single branch. This type of
repository structure is fine for linear development supporting a single
machine and architecture. However, if you work with multiple boards and
architectures, a kernel source repository with multiple branches is more
@@ -772,7 +772,7 @@ board to boot. Sometimes, these patches are works-in-progress or
fundamentally wrong, yet they are still necessary for specific boards.
In these situations, you most likely do not want to include these
patches in every kernel you build (i.e. have the patches as part of the
lone "master" branch). It is situations like these that give rise to
default branch). It is situations like these that give rise to
multiple branches used within a Linux kernel sources Git repository.
Here are repository organization strategies maximizing source reuse,
@@ -812,7 +812,7 @@ Machine Branches
When you have multiple machines and architectures to support, or you are
actively working on board support, it is more efficient to create
branches in the repository based on individual machines. Having machine
branches allows common source to remain in the "master" branch with any
branches allows common source to remain in the development branch with any
features specific to a machine stored in the appropriate machine branch.
This organization method frees you from continually reintegrating your
patches into a feature.