diff options
author | Robert P. J. Day <rpjday@crashcourse.ca> | 2014-08-01 09:01:45 +0300 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2014-08-02 10:00:26 +0100 |
commit | f937e05b44f6b46ba60c4d3a18f57bb78b0ec7c0 (patch) | |
tree | 36c191bb4386e99ea36f89372c79f22fc4cb5f64 /documentation/dev-manual | |
parent | 3152e693837e72d08a2eda58bb81eefcd4150250 (diff) | |
download | ast2050-yocto-poky-f937e05b44f6b46ba60c4d3a18f57bb78b0ec7c0.zip ast2050-yocto-poky-f937e05b44f6b46ba60c4d3a18f57bb78b0ec7c0.tar.gz |
dev-manual: Miscellaneous fixes in the newbie chapter.
(From yocto-docs rev: 34d6bd814e813591631b336f6247c300381fd309)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r-- | documentation/dev-manual/dev-manual-newbie.xml | 42 |
1 files changed, 21 insertions, 21 deletions
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 0f7708e..f5f23f4 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -41,7 +41,7 @@ </para> <para> - A benchmark example of an open source project is the Linux Kernel, which was initially conceived + A benchmark example of an open source project is the Linux kernel, which was initially conceived and created by Finnish computer science student Linus Torvalds in 1991. Conversely, a good example of a non-open source project is the <trademark class='registered'>Windows</trademark> family of operating @@ -443,7 +443,7 @@ </para></listitem> <listitem><para> Be sure to always work in matching branches for both - the <filename>meta-intel</filename> repository and the + the selected BSP repository and the <link linkend='source-directory'>Source Directory</link> (i.e. <filename>poky</filename>) repository. For example, if you have checked out the "master" branch @@ -508,7 +508,8 @@ The filenames can differ only in the file type suffix used (e.g. <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>). </para> - <para>Information in append files overrides the information in the similarly-named recipe file. + <para>Information in append files extends or overrides the + information in the similarly-named recipe file. For an example of an append file in use, see the "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section. <note> @@ -669,7 +670,7 @@ chapter in the Yocto Project Reference Manual.</para></listitem> <listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core, a BSP, or an application stack. - For a discussion on BSP Layers, see the + For a discussion specifically on BSP Layers, see the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the Yocto Project Board Support Packages (BSP) Developer's Guide.</para></listitem> @@ -699,7 +700,7 @@ <para>It is worth noting that the term "package" can, in general, have subtle meanings. For example, the packages referred to in the "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are - compiled binaries that when installed add functionality to your Linux + compiled binaries that, when installed, add functionality to your Linux distribution.</para> <para>Another point worth noting is that historically within the Yocto Project, recipes were referred to as packages - thus, the existence of several BitBake @@ -733,12 +734,11 @@ the Yocto Project.</para></listitem> <listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages. - A recipe describes where you get source code and which patches - to apply. - Recipes describe dependencies for libraries or for other - recipes, and they also contain configuration and compilation - options. - Recipes contain the logical unit of execution, the software + A recipe describes where you get source code, which patches + to apply, how to configure the source, how to compile it and so on. + Recipes also describe dependencies for libraries or for other + recipes. + Recipes represent the logical unit of execution, the software to build, the images to build, and use the <filename>.bb</filename> file extension. </para></listitem> @@ -778,7 +778,7 @@ folder is also named "poky".</para> <para>While it is not recommended that you use tarball expansion - to setup the Source Directory, if you do, the top-level + to set up the Source Directory, if you do, the top-level directory name of the Source Directory is derived from the Yocto Project release tarball. For example, downloading and unpacking @@ -844,7 +844,7 @@ license is distributed with that software. MIT is also compatible with the GNU General Public License (GPL). Patches to the Yocto Project follow the upstream licensing scheme. - You can find information on the MIT license at + You can find information on the MIT license <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>. You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'> here</ulink>. @@ -976,7 +976,7 @@ Each of these branches represents a specific area of development. The <filename>master</filename> branch represents the current or most recent development. - All other branches represent off-shoots of the <filename>master</filename> + All other branches represent offshoots of the <filename>master</filename> branch. </para> @@ -1029,7 +1029,7 @@ <para> Some key tags are <filename>dylan-9.0.0</filename>, - <filename>dora-10.0.0</filename>, + <filename>dora-10.0.0</filename>, <filename>daisy-11.0.0</filename>, and <filename>&DISTRO_NAME;-&POKYVERSION;</filename>. These tags represent Yocto Project releases. </para> @@ -1175,10 +1175,10 @@ For the Yocto Project, a key individual called the "maintainer" is responsible for the "master" branch of a given Git repository. 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 + The maintainer is responsible for accepting changes from other developers and for organizing the underlying branch structure to reflect release strategies and so forth. - <note>For information on finding out who is responsible (maintains) - for a particular area of code, see the + <note>For information on finding out who is responsible for (maintains) + a particular area of code, see the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section. </note> @@ -1332,9 +1332,9 @@ a bug.</para></listitem> <listitem><para>When submitting a new bug, be sure to choose the appropriate Classification, Product, and Component for which the issue was found. - Defects for the Yocto Project fall into one of six classifications: Yocto Project - Components, Infrastructure, Build System & Metadata, Documentation, - QA/Testing, and Runtime. + Defects for the Yocto Project fall into one of seven classifications: + Yocto Project Components, Infrastructure, Build System & Metadata, + Documentation, QA/Testing, Runtime and Hardware. Each of these Classifications break down into multiple Products and, in some cases, multiple Components.</para></listitem> <listitem><para>Use the bug form to choose the correct Hardware and Architecture |