diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 46b680e6be..779d06d57e 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -12,9 +12,9 @@
closed, proprietary environment.
Additionally, the Yocto Project uses specific tools and constructs as part of its development
environment.
- This chapter specifically addresses open source philosophy, using the
+ This chapter specifically addresses open source philosophy, using the
Yocto Project in a team environment, source repositories, Yocto Project
- terms, licensing, the open source distributed version control system Git,
+ terms, licensing, the open source distributed version control system Git,
workflows, bug tracking, and how to submit changes.
@@ -190,15 +190,15 @@
extensive testing while they continue to develop
locally using their primary development system.
- Enable the PR Service when package feeds
- need to be incremental with continually increasing
- PR
+ Enable the PR Service when package feeds
+ need to be incremental with continually increasing
+ PR
values.
- Typically, this situation occurs when you use or
+ Typically, this situation occurs when you use or
publish package feeds and use a shared state.
You should enable the PR Service for all users who
use the shared state pool.
- For more information on the PR Service, see the
+ For more information on the PR Service, see the
"Working With a PR Service".
@@ -218,9 +218,9 @@
Of the SCMs BitBake supports, the
Yocto Project team strongly recommends using
Git.
- Git is a distributed system that is easy to backup
- (each checkout is a backup in itself), allows you to work
- remotely, and then connects back to the infrastructure.
+ Git is a distributed system that is easy to backup,
+ allows you to work remotely, and then connects back to the
+ infrastructure.
For information about BitBake and SCMs, see the
BitBake manual located in the
@@ -428,8 +428,8 @@
- For any supported release of Yocto Project, you can go to the
- Yocto Project Website and
+ For any supported release of Yocto Project, you can go to the
+ Yocto Project Website and
select the "Downloads" tab and get a tarball of the release.
You can also go to this site to download any supported BSP tarballs.
Unpacking the tarball gives you a hierarchical Source Directory that lets you develop
@@ -461,7 +461,7 @@
- "Downloads" page for the
+ "Downloads" page for the
Yocto Project Website:
Access this page by going to the website and then selecting
the "Downloads" tab.
@@ -489,7 +489,7 @@
Append files are known as BitBake append files and .bbappend files.
The OpenEmbedded build system expects every append file to have a corresponding
recipe (.bb) file.
- Furthermore, the append file and corresponding recipe file
+ Furthermore, the append file and corresponding recipe file
must use the same root filename.
The filenames can differ only in the file type suffix used (e.g.
formfactor_0.0.bb and formfactor_0.0.bbappend).
@@ -641,7 +641,7 @@
OE-Core: A core set of Metadata originating
with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
- This Metadata is found in the meta directory of the
+ This Metadata is found in the meta directory of the
Source Directory.Package: In the context of the Yocto Project,
this term refers to the packaged output from a baked recipe.
@@ -776,7 +776,7 @@
When you build an image using the Yocto Project, the build process uses a
known list of licenses to ensure compliance.
- You can find this list in the
+ You can find this list in the
Source Directory at
meta/files/common-licenses.
Once the build completes, the list of all licenses found and used during that build are
@@ -869,7 +869,7 @@
When you clone a Git repository, you end up with an identical copy of the
repository on your development system.
Once you have a local copy of a repository, you can take steps to develop locally.
- For examples on how to clone Git repositories, see the
+ For examples on how to clone Git repositories, see the
"Getting Set Up" section.
@@ -911,14 +911,14 @@
$ cd poky
$ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
- In this example, the name of the top-level directory of your local
- Source Directory
+ In this example, the name of the top-level directory of your local
+ Source Directory
is poky,
- and the name of that local working area (local branch) you just
+ and the name of that local working area (local branch) you just
created and checked out is &DISTRO_NAME;.
- The files in your local repository now reflect the same files that
- are in the &DISTRO_NAME; development
- branch of the Yocto Project's poky
+ The files in your local repository now reflect the same files that
+ are in the &DISTRO_NAME; development
+ branch of the Yocto Project's poky
upstream repository.
It is important to understand that when you create and checkout a
local working branch based on a branch name,
@@ -1037,10 +1037,10 @@
repository and places it in your local Git repository.
You use this command to make sure you are synchronized with the repository
from which you are basing changes (.e.g. the master branch).
- git push:
- Sends all your committed local changes to an upstream Git
+ git push:
+ Sends all your committed local changes to an upstream Git
repository (e.g. a contribution repository).
- The maintainer of the project draws from these repositories
+ The maintainer of the project draws from these repositories
when adding changes to the project’s master repository or
other development branch.
@@ -1088,8 +1088,8 @@
The "master" branch is the “upstream” repository where the final builds of the project occur.
The maintainer is responsible for allowing changes in from other developers and for
organizing the underlying branch structure to reflect release strategies and so forth.
- For information on finding out who is responsible (maintains)
- for a particular area of code, see the
+ For information on finding out who is responsible (maintains)
+ for a particular area of code, see the
"How to Submit a Change"
section.
@@ -1160,8 +1160,8 @@
You can name these branches anything you like.
It is helpful to give them names associated with the particular feature or change
on which you are working.
- Once you are done with a feature or change and have merged it
- into your local master branch, simply discard the temporary
+ Once you are done with a feature or change and have merged it
+ into your local master branch, simply discard the temporary
branch.Merge Changes: The git merge
command allows you to take the
@@ -1189,9 +1189,9 @@
send-pull-request that ship with the release to facilitate this
workflow.
You can find these scripts in the scripts
- folder of the
+ folder of the
Source Directory.
- For information on how to use these scripts, see the
+ For information on how to use these scripts, see the
"Using Scripts to Push a Change Upstream and Request a Pull" section.
Patch Workflow: This workflow allows you to notify the
@@ -1199,7 +1199,7 @@
for the "master" branch of the Git repository.
To send this type of change, you format the patch and then send the email using the Git commands
git format-patch and git send-email.
- For information on how to use these scripts, see the
+ For information on how to use these scripts, see the
"How to Submit a Change"
section.
@@ -1251,10 +1251,10 @@
Provide a detailed description of the issue.
You should provide as much detail as you can about the context, behavior, output,
and so forth that surrounds the issue.
- You can even attach supporting files for output from logs by
+ You can even attach supporting files for output from logs by
using the "Add an attachment" button.
- Be sure to copy the appropriate people in the
- "CC List" for the bug.
+ Be sure to copy the appropriate people in the
+ "CC List" for the bug.
See the "How to Submit a Change"
section for information about finding out who is responsible
for code.
@@ -1281,37 +1281,37 @@
or notifying:
Maintenance File:
- Examine the maintainers.inc file, which is
- located in the
+ Examine the maintainers.inc file, which is
+ located in the
Source Directory
- at meta-yocto/conf/distro/include, to
+ at meta-yocto/conf/distro/include, to
see who is responsible for code.
Board Support Package (BSP) README Files:
- For BSP maintainers of supported BSPs, you can examine
+ For BSP maintainers of supported BSPs, you can examine
individual BSP README files.
- Alternatively, you can examine the
- MAINTAINERS file, which is found in the
+ Alternatively, you can examine the
+ MAINTAINERS file, which is found in the
meta-intel, for a list of all supported
BSP maintainers.
Search by File:
- Using Git, you can enter the
- following command to bring up a short list of all commits
+ Using Git, you can enter the
+ following command to bring up a short list of all commits
against a specific file:
git shortlog -- <filename>
Just provide the name of the file for which you are interested.
- The information returned is not ordered by history but does
- include a list of all committers grouped by name.
+ The information returned is not ordered by history but does
+ include a list of all committers grouped by name.
From the list, you can see who is responsible for the bulk of
the changes against the file.
-
+
For a list of the Yocto Project and related mailing lists, see the
"Mailing lists" section in
the Yocto Project Reference Manual.
@@ -1320,7 +1320,7 @@
Here is some guidance on which mailing list to use for what type of change:
- For changes to the core
+ For changes to the core
Metadata, send your patch to the
openembedded-core mailing list.
For example, a change to anything under the meta or
@@ -1435,7 +1435,7 @@
- The next two sections describe general instructions for both pushing
+ The next two sections describe general instructions for both pushing
changes upstream and for submitting changes as patches.
@@ -1493,7 +1493,7 @@
Depending on the components changed, you need to submit the email to a specific
mailing list.
For some guidance on which mailing list to use, see the list in the
- "How to Submit a Change"
+ "How to Submit a Change"
section.
For a description of the available mailing lists, see the
"Mailing Lists"
@@ -1521,8 +1521,8 @@
To format commits, use the git format-patch command.
When you provide the command, you must include a revision list or a number of patches
as part of the command.
- For example, either of these two commands takes your most
- recent single commit and formats it as an email message in
+ For example, either of these two commands takes your most
+ recent single commit and formats it as an email message in
the current directory:
$ git format-patch -1
@@ -1534,7 +1534,7 @@
After the command is run, the current directory contains a
numbered .patch file for the commit.If you provide several commits as part of the command,
- the git format-patch command produces a
+ the git format-patch command produces a
series of numbered files in the current directory – one for each commit.
If you have more than one patch, you should also use the
--cover option with the command, which generates a
@@ -1571,7 +1571,7 @@
The command also has several options that let you
specify recipients and perform further editing of the email message.
For information on how to use the git send-email command,
- see GIT-SEND-EMAIL(1) displayed using
+ see GIT-SEND-EMAIL(1) displayed using
the man git-send-email command.