documentation: dev-manual - Final changes before 1.3 lockdown.

Made minor changes as needed due to some new sections, links,
and capitalization standards.

(From yocto-docs rev: bc966e5a78dadd14ecf1896a36e40a9b256bae77)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

4 files changed, 79 insertions, 71 deletions

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 20742ad539..b909305f68 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -208,7 +208,7 @@
                 To enable your layer, simply add your layer's path to the 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'>BBLAYERS</ulink></filename> 
                 variable in your <filename>conf/bblayers.conf</filename> file, which is found in the 
-                <link linkend='build-directory'>build directory</link>. 
+                <link linkend='build-directory'>Build Directory</link>. 
                 The following example shows how to enable a layer named <filename>meta-mylayer</filename>:
                 <literallayout class='monospaced'>
      LCONF_VERSION = "6"
@@ -315,7 +315,7 @@
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
-     PRINC := "${@int(PRINC) + 1}"
+     PRINC := "${@int(PRINC) + 2}"
                 </literallayout>
                 This example adds or overrides files in 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
@@ -581,7 +581,7 @@
                 You can also add more features by configuring the 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</ulink></filename>
                 variable in the <filename>local.conf</filename> file found in the Source Directory
-                located in the build directory.
+                located in the Build Directory.
             </para>
 
             <para>
@@ -1240,7 +1240,7 @@
                 combination of multiple libraries you want to build. 
                 You accomplish this through your <filename>local.conf</filename>
                 configuration file in the 
-                <link linkend='build-directory'>build directory</link>. 
+                <link linkend='build-directory'>Build Directory</link>. 
                 An example configuration would be as follows:
                 <literallayout class='monospaced'>
      MACHINE = "qemux86-64"
@@ -1285,7 +1285,7 @@
                     <listitem><para>A unique architecture is defined for the Multilib packages,
                         along with creating a unique deploy folder under 
                         <filename>tmp/deploy/rpm</filename> in the 
-                        <link linkend='build-directory'>build directory</link>. 
+                        <link linkend='build-directory'>Build Directory</link>. 
                         For example, consider <filename>lib32</filename> in a 
                         <filename>qemux86-64</filename> image. 
                         The possible architectures in the system are "all", "qemux86_64",
@@ -1407,7 +1407,7 @@
                 Saving the selections updates the <filename>.config</filename> configuration file.
                 This is the file that the OpenEmbedded build system uses to configure the 
                 kernel during the build. 
-                You can find and examine this file in the build directory in 
+                You can find and examine this file in the Build Directory in 
                 <filename>tmp/work/</filename>.
                 The actual <filename>.config</filename> is located in the area where the 
                 specific kernel is built.
@@ -1463,7 +1463,7 @@
                 placed where the OpenEmbedded build system can find and apply them.
                 Syntactically, the configuration statement is identical to what would appear
                 in the <filename>.config</filename> file, which is in the 
-                <link linkend='build-directory'>build directory</link> in 
+                <link linkend='build-directory'>Build Directory</link> in 
                 <filename>tmp/work/&lt;arch&gt;-poky-linux/linux-yocto-&lt;release-specific-string&gt;/linux-&lt;arch&gt;-&lt;build-type&gt;</filename>.
             </para>
 
@@ -1801,7 +1801,7 @@
                 <itemizedlist>
                     <listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> Your
                         selected <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                        definition within the <filename>local.conf</filename> file in the build directory 
+                        definition within the <filename>local.conf</filename> file in the Build Directory 
                         specifies the target architecture used when building the Linux kernel.
                         By default, <filename>MACHINE</filename> is set to 
                         <filename>qemux86</filename>, which specifies a 32-bit 
@@ -1847,12 +1847,12 @@
                         </para></listitem>
                     <listitem><para><emphasis>Clean up</emphasis>:
                         Be sure to clean the shared state out by running the 
-                        <filename>cleansstate</filename> BitBake task as follows from your build directory:
+                        <filename>cleansstate</filename> BitBake task as follows from your Build Directory:
                         <literallayout class='monospaced'>
      $ bitbake -c cleansstate linux-yocto
                         </literallayout></para>
                         <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
-                        directory inside the build directory.
+                        directory inside the Build Directory.
                         Always use the various BitBake clean tasks to clear out previous 
                         build artifacts.
                         </note></para></listitem>
@@ -2022,7 +2022,7 @@
 
         <para>
             By default, the OpenEmbedded build system does its work from within the 
-            <link linkend='build-directory'>build directory</link>.  
+            <link linkend='build-directory'>Build Directory</link>.  
             The build process involves fetching the source files, unpacking them, and then patching them
             if necessary before the build takes place.
         </para>
@@ -2058,17 +2058,17 @@
 
         <para>
             It is important to know that the <filename>externalsrc.bbclass</filename> assumes that the 
-            source directory <filename>S</filename> and the build directory 
+            source directory <filename>S</filename> and the Build Directory 
             <ulink url='&YOCTO_DOCS_REF_URL;#var-B'><filename>B</filename></ulink>
             are different even though by default these directories are the same.
             This assumption is important because it supports building different variants of the recipe
             by using the 
             <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
             variable.
-            You could allow the build directory to be the same as the source directory but you would 
+            You could allow the Build Directory to be the same as the source directory but you would 
             not be able to build more than one variant of the recipe.
             Consequently, if you are building multiple variants of the recipe, you need to establish a 
-            build directory that is different than the source directory.
+            Build Directory that is different than the source directory.
         </para>
     </section>
 
@@ -2114,7 +2114,7 @@
         <para>
             To enable this behavior, simply add the following to the <filename>local.conf</filename>
             configuration file found in the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>:
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
             <literallayout class='monospaced'>
      SRCREV_pn-&lt;PN&gt; = "${AUTOREV}"
             </literallayout>
@@ -2545,7 +2545,7 @@
                 </para>
 
                 <para>
-                    Downloaded archives reside in the build directory in 
+                    Downloaded archives reside in the Build Directory in 
                     <filename>/tmp</filename> and are cleared up when they are no longer in use.
                 </para>
 
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index 4452d2a4e2..c14c524aa5 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -236,7 +236,7 @@
             "<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
             for an example that changes the source code of the kernel.
             For information on how to configure the kernel, see the 
-            "<link linkend='configuring-the-kernel'>Configuring the Kernel</link> section.
+            "<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section.
         </para>
 
         <section id='kernel-overview'>
@@ -347,7 +347,8 @@
                 What happens during the build?  
                 When you build the kernel on your development system, all files needed for the build
                 are taken from the source repositories pointed to by the 
-                <filename>SRC_URI</filename> variable and gathered in a temporary work area
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable 
+                and gathered in a temporary work area
                 where they are subsequently used to create the unique kernel.
                 Thus, in a sense, the process constructs a local source tree specific to your 
                 kernel to generate the new kernel image - a source generator if you will.
@@ -394,8 +395,8 @@
                         "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
                     <listitem><para><emphasis>Establish a local copy of project files on your 
-                        system</emphasis>:  Having the <link linkend='source-directory'>source
-                        directory</link> on your system gives you access to the build process and tools 
+                        system</emphasis>:  Having the <link linkend='source-directory'>Source
+                        Directory</link> on your system gives you access to the build process and tools 
                         you need.
                         For information on how to get these files, see the bulleted item
                         "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
@@ -439,7 +440,7 @@
                         <filename>.config</filename>.
                         Try to resist the temptation of directly editing the <filename>.config</filename> 
                         file found in the 
-                        <link linkend='build-directory'>build directory</link> at 
+                        <link linkend='build-directory'>Build Directory</link> at 
                         <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
                         Doing so, can produce unexpected results when the OpenEmbedded build system 
                         regenerates the configuration file.</para>
@@ -986,10 +987,10 @@
                                        <listitem><para><emphasis>
                                             <filename>Build System Derived Toolchain:</filename></emphasis> 
                                             Select this mode if the cross-toolchain has been installed and built 
-                                            as part of the build directory.  
+                                            as part of the Build Directory.  
                                             When you select <filename>Build system derived toolchain</filename>,
                                             you are using the toolchain bundled 
-                                            inside the build directory.
+                                            inside the Build Directory.
                                             </para></listitem>
                                     </itemizedlist>
                                 </para></listitem>
@@ -1008,9 +1009,9 @@
                                 However, doing so is discouraged.</note></para>
                                 <para>If you are using a system-derived toolchain, the path you provide 
                                 for the <filename>Toolchain Root Location</filename>
-                                field is the build directory.
+                                field is the Build Directory.
                                 See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using 
-                                BitBake and the build directory</ulink>" section in the Yocto Project Application
+                                BitBake and the Build Directory</ulink>" section in the Yocto Project Application
                                 Developer's Guide for information on how to install the toolchain into the build 
 directory.</para></listitem> 
                             <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
@@ -1053,7 +1054,7 @@ directory.</para></listitem>
                                 and specify any custom options.</para>
                                 <para>If you selected <filename>Build system derived toolchain</filename>, 
                                 the target kernel you built will be located in the 
-                                build directory in <filename>tmp/deploy/images</filename> directory.   
+                                Build Directory in <filename>tmp/deploy/images</filename> directory.   
                                 If you selected <filename>Standalone pre-built toolchain</filename>, the 
                                 pre-built image you downloaded is located 
                                 in the directory you specified when you downloaded the image.</para>
@@ -1409,7 +1410,7 @@ directory.</para></listitem>
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
                         <listitem><para>Select <filename>Project -> Launch HOB</filename>.</para></listitem>
-                        <listitem><para>Enter the build directory where you want to put your final images.</para></listitem>
+                        <listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem>
                         <listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem>
                         <listitem><para>Use Hob to customize and build your own images. 
                             For information on Hob, see the 
@@ -1480,7 +1481,7 @@ directory.</para></listitem>
         to figure out your solution.
         After you have initially built the package, you can iteratively tweak the 
         source code, which is located in the 
-        <link linkend='build-directory'>build directory</link>, and then 
+        <link linkend='build-directory'>Build Directory</link>, and then 
         you can force a re-compile and quickly test your altered code.
         Once you settle on a solution, you can then preserve your changes in the form of 
         patches.
@@ -1494,7 +1495,7 @@ directory.</para></listitem>
 
         <para>
             During a build, the unpacked temporary source code used by recipes 
-            to build packages is available in the build directory as 
+            to build packages is available in the Build Directory as 
             defined by the 
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable.
             Below is the default value for the <filename>S</filename> variable as defined in the 
@@ -1528,7 +1529,7 @@ directory.</para></listitem>
             Let's look at an example without variables.
             Assuming a top-level <link linkend='source-directory'>Source Directory</link>
             named <filename>poky</filename>
-            and a default build directory of <filename>poky/build</filename>, 
+            and a default Build Directory of <filename>poky/build</filename>, 
             the following is the work directory for the <filename>acl</filename> recipe that 
             creates the <filename>acl</filename> package:
             <literallayout class='monospaced'>
@@ -1543,7 +1544,7 @@ directory.</para></listitem>
      ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
             </literallayout>
             Again, assuming top-level Source Directory named <filename>poky</filename>
-            and a default build directory of <filename>poky/build</filename>, the 
+            and a default Build Directory of <filename>poky/build</filename>, the 
             following are the work and temporary source directories, respectively,
             for the <filename>acl</filename> package that is being 
             built for a MIPS-based device:
@@ -1591,7 +1592,7 @@ directory.</para></listitem>
             <orderedlist>
                 <listitem><para><emphasis>Find the Source Code:</emphasis>
                     The temporary source code used by the OpenEmbedded build system is kept in the 
-                    build directory.  
+                    Build Directory.  
                     See the 
                     "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
                     section to learn how to locate the directory that has the temporary source code for a 
@@ -1689,7 +1690,7 @@ directory.</para></listitem>
             <orderedlist>
                 <listitem><para><emphasis>Find the Source Code:</emphasis>
                     The temporary source code used by the OpenEmbedded build system is kept in the 
-                    build directory.  
+                    Build Directory.  
                     See the 
                     "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
                     section to learn how to locate the directory that has the temporary source code for a 
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 20cf234a6b..bb01131c05 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -130,7 +130,7 @@
         From the interface, you can click on any particular item in the "Name" column and 
         see the URL at the bottom of the page that you need to set up a Git repository for 
         that particular item.
-        Having a local Git repository of the source directory (poky) allows you to 
+        Having a local Git repository of the Source Directory (poky) allows you to 
         make changes, contribute to the history, and ultimately enhance the Yocto Project's 
         tools, Board Support Packages, and so forth.
     </para>
@@ -148,7 +148,7 @@
         <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> 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 
+        Unpacking the tarball gives you a hierarchical Source Directory that lets you develop 
         using the Yocto Project.
     </para>
 
@@ -220,31 +220,31 @@
                 <para id='build-directory'><emphasis>Build Directory:</emphasis>
                 This term refers to the area used by the OpenEmbedded build system for builds.  
                 The area is created when you <filename>source</filename> the setup 
-                environment script that is found in the source directory
-                (i.e. <filename>oe-init-build-env</filename>).
+                environment script that is found in the Source Directory
+                (i.e. <filename>&OE_INIT_FILE;</filename>).
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
-                variable points to the build directory.</para>
+                variable points to the Build Directory.</para>
            
-                <para>You have a lot of flexibility when creating the build directory.
+                <para>You have a lot of flexibility when creating the Build Directory.
                 Following are some examples that show how to create the directory:
                    <itemizedlist>
-                        <listitem><para>Create the build directory in your current working directory
+                        <listitem><para>Create the Build Directory in your current working directory
                             and name it <filename>build</filename>.
                             This is the default behavior.
                             <literallayout class='monospaced'>
-     $ source oe-init-build-env
+     $ source &OE_INIT_PATH;
                             </literallayout></para></listitem>
                         <listitem><para>Provide a directory path and specifically name the build 
                             directory. 
-                            This next example creates a build directory named <filename>YP-&POKYVERSION;</filename>
+                            This next example creates a Build Directory named <filename>YP-&POKYVERSION;</filename>
                             in your home directory within the directory <filename>mybuilds</filename>.
                             If <filename>mybuilds</filename> does not exist, the directory is created for you:
                             <literallayout class='monospaced'> 
      $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
                             </literallayout></para></listitem>
-                        <listitem><para>Provide an existing directory to use as the build directory.
+                        <listitem><para>Provide an existing directory to use as the Build Directory.
                             This example uses the existing <filename>mybuilds</filename> directory 
-                            as the build directory.
+                            as the Build Directory.
                             <literallayout class='monospaced'> 
      $ source &OE_INIT_PATH; $HOME/mybuilds/
                             </literallayout></para></listitem>
@@ -254,7 +254,7 @@
                 this term refers to the OpenEmbedded build system used by the project. 
                 This build system is based on the project known as "Poky."
                 For some historical information about Poky, see the 
-                <link linkend='poky'>poky</link> term further along in this section.
+                <link linkend='poky'>Poky</link> term further along in this section.
                 </para></listitem>
             <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
                 and inheritance allowing commonly used patterns to be defined once and easily used 
@@ -264,14 +264,14 @@
             <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in various
                 <filename>.conf</filename> files provides global definitions of variables.
                 The <filename>conf/local.conf</filename> configuration file in the 
-                <link linkend='build-directory'>build directory</link>
+                <link linkend='build-directory'>Build Directory</link>
                 contains user-defined variables that affect each build.
                 The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
                 defines Yocto ‘distro’ configuration
                 variables used only when building with this policy.  
                 Machine configuration files, which 
                 are located throughout the 
-                <link linkend='source-directory'>source directory</link>, define
+                <link linkend='source-directory'>Source Directory</link>, define
                 variables for specific hardware and are only used when building for that target 
                 (e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines 
                 variables for the Texas Instruments ARM Cortex-A8 development board).  
@@ -332,7 +332,7 @@
                 the Yocto Project's build system.
                 Within the Yocto Project source repositories, poky exists as a separate Git repository
                 that can be cloned to yield a local copy on the host system. 
-                Thus, "poky" can refer to the local copy of the source directory used to develop within
+                Thus, "poky" can refer to the local copy of the Source Directory used to develop within
                 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.
@@ -349,15 +349,15 @@
                 Sometimes you might here the term "poky directory" used to refer to this 
                 directory structure.</para>
 
-                <para>The source directory contains BitBake, Documentation, metadata and 
+                <para>The Source Directory contains BitBake, Documentation, metadata and 
                 other files that all support the Yocto Project. 
-                Consequently, you must have the source directory in place on your development 
+                Consequently, you must have the Source Directory in place on your development 
                 system in order to do any development using the Yocto Project.</para>
 
-                <para>For tarball expansion, the name of the top-level directory of the source directory  
+                <para>For tarball expansion, the name of the top-level directory of the Source Directory  
                 is derived from the Yocto Project release tarball.
                 For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
-                results in a source directory whose top-level folder is named 
+                results in a Source Directory whose top-level folder is named 
                 <filename>&YOCTO_POKY;</filename>.
                 If you create a local copy of the Git repository, then you can name the repository 
                 anything you like.
@@ -366,15 +366,15 @@
                 So, for example, cloning the <filename>poky</filename> Git repository results in a 
                 local Git repository whose top-level folder is also named <filename>poky</filename>.</para>
 
-                <para>It is important to understand the differences between the source directory created
+                <para>It is important to understand the differences between the Source Directory created
                 by unpacking a released tarball as compared to cloning 
                 <filename>git://git.yoctoproject.org/poky</filename>.
                 When you unpack a tarball, you have an exact copy of the files based on the time of 
                 release - a fixed release point.
-                Any changes you make to your local files in the source directory are on top of the release.
+                Any changes you make to your local files in the Source Directory are on top of the release.
                 On the other hand, when you clone the <filename>poky</filename> Git repository, you have an
                 active development repository.
-                In this case, any local changes you make to the source directory can be later applied 
+                In this case, any local changes you make to the Source Directory can be later applied 
                 to active development branches of the upstream <filename>poky</filename> Git 
                 repository.</para>
 
@@ -438,7 +438,7 @@
         <filename>meta/files/common-licenses</filename>.  
         Once the build completes, the list of all licenses found and used during that build are 
         kept in the 
-        <link linkend='build-directory'>build directory</link> at 
+        <link linkend='build-directory'>Build Directory</link> at 
         <filename>tmp/deploy/images/licenses</filename>.
     </para>
 
@@ -466,6 +466,12 @@
         <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
         This wiki page discusses the license infrastructure used by the Yocto Project.
     </para>
+
+    <para>
+        For information that can help you to maintain compliance with various open source licensing 
+        during the lifecycle of a product created using the Yocto Project, see the 
+        "<link linkend='maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</link>" section.
+    </para>
 </section>
 
 <section id='git'>
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index e55a07d87a..11d4adca9f 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -56,8 +56,9 @@
                 OpenSUSE, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
                 and officially supported. 
                 For a list of the distributions under validation and their status, see the
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution
-                Support</ulink> wiki page.</para>
+                "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
+                in the Yocto Project Reference Manual and the wiki page at 
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>.</para>
                 <para>
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
@@ -69,12 +70,12 @@
                 for the supported distributions.</para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>  
                 You need a release of the Yocto Project.  
-                You set up a with local <link linkend='source-directory'>source directory</link>
+                You set up a with local <link linkend='source-directory'>Source Directory</link>
                 one of two ways depending on whether you 
                 are going to contribute back into the Yocto Project or not.
                 <note>
                     Regardless of the method you use, this manual refers to the resulting local
-                    hierarchical set of files as the "source directory."
+                    hierarchical set of files as the "Source Directory."
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  If you are not going to contribute 
@@ -83,7 +84,7 @@
                         Once you have the tarball, just extract it into a directory of your choice.</para>
                         <para>For example, the following command extracts the Yocto Project &DISTRO; 
                         release tarball 
-                        into the current working directory and sets up the local source directory
+                        into the current working directory and sets up the local Source Directory
                         with a top-level folder named <filename>&YOCTO_POKY;</filename>:
                         <literallayout class='monospaced'>
      $ tar xfj &YOCTO_POKY_TARBALL;
@@ -125,11 +126,11 @@
                 You can find Git repositories of supported Yocto Project Kernels organized under
                 "Yocto Linux Kernel" in the Yocto Project Source Repositories at
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
-                <para>This setup involves creating a bare clone of the Yocto Project kernel and then 
+                <para>This setup can involve creating a bare clone of the Yocto Project kernel and then 
                 copying that cloned repository.
                 You can create the bare clone and the copy of the bare clone anywhere you like.
                 For simplicity, it is recommended that you create these structures outside of the 
-                source directory (usually <filename>poky</filename>).</para>
+                Source Directory (usually <filename>poky</filename>).</para>
                 <para>As an example, the following transcript shows how to create the bare clone
                 of the <filename>linux-yocto-3.4</filename> kernel and then create a copy of 
                 that clone.
@@ -168,9 +169,9 @@
                 <para>You can find the <filename>poky-extras</filename> Git Repository in the 
                 "Yocto Metadata Layers" area of the Yocto Project Source Repositories at 
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
-                It is good practice to create this Git repository inside the source directory.</para>
+                It is good practice to create this Git repository inside the Source Directory.</para>
                 <para>Following is an example that creates the <filename>poky-extras</filename> Git 
-                repository inside the source directory, which is named <filename>poky</filename> 
+                repository inside the Source Directory, which is named <filename>poky</filename> 
                 in this case:
                 <literallayout class='monospaced'>
      $ cd ~/poky
@@ -192,7 +193,7 @@
                 layer.  
                 You can get set up for BSP development one of two ways: tarball extraction or
                 with a local Git repository.
-                It is a good idea to use the same method that you used to set up the source directory.
+                It is a good idea to use the same method that you used to set up the Source Directory.
                 Regardless of the method you use, the Yocto Project uses the following BSP layer 
                 naming scheme:
                 <literallayout class='monospaced'> 
@@ -218,13 +219,13 @@
                         Again, this method just produces a snapshot of the BSP layer in the form
                         of a hierarchical directory structure.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working 
-                        with a local Git repository for your source directory, you should also use this method 
+                        with a local Git repository for your Source Directory, you should also use this method 
                         to set up the <filename>meta-intel</filename> Git repository.
                         You can locate the <filename>meta-intel</filename> Git repository in the 
                         "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
                         <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
                         <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
-                        the source directory.
+                        the Source Directory.
                         For example, the following transcript shows the steps to clone the 
                         <filename>meta-intel</filename>
                         Git repository inside the local <filename>poky</filename> Git repository.
@@ -266,13 +267,13 @@
     <para>
         The build process is as follows:
         <orderedlist>
-            <listitem><para>Make sure you have set up the source directory described in the 
+            <listitem><para>Make sure you have set up the Source Directory described in the 
                 previous section.</para></listitem>
             <listitem><para>Initialize the build environment by sourcing a build environment 
                 script.</para></listitem>
             <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file,
                 which is found in the 
-                <link linkend='build-directory'>build directory</link>, 
+                <link linkend='build-directory'>Build Directory</link>, 
                 is set up how you want it.  
                 This file defines many aspects of the build environment including 
                 the target machine architecture through the 
@@ -298,7 +299,7 @@
     <para>
         Another option you have to get started is to use pre-built binaries. 
         The Yocto Project provides many types of binaries with each release. 
-        See the <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>
+        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
         chapter in the Yocto Project Reference Manual
         for descriptions of the types of binaries that ship with a Yocto Project
         release.