mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-04 23:02:22 +02:00
Code Issues Packages Projects Releases Wiki Activity

make the documentation a bit more inclusive

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/kernel-dev/advanced.rst
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.

4
documentation/kernel-dev/concepts-appx.rst
View File

@@ -211,8 +211,8 @@ view, there is a linear path that travels from the baseline
``kernel.org``, through a select group of features and ends with their
BSP-specific commits. In other words, the divisions of the kernel are
transparent and are not relevant to the developer on a day-to-day basis.
From the developer's perspective, this path is the "master" branch in
Git terms. The developer does not need to be aware of the existence of
From the developer's perspective, this path is the development branch.
The developer does not need to be aware of the existence of
any other branches at all. Of course, it can make sense to have these
branches in the tree, should a person decide to explore them. For
example, a comparison between two BSPs at either the commit level or at