1 files changed, 18 insertions, 11 deletions

diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index 51fb3f4f4f..8a5ad73f86 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -31,7 +31,7 @@
         The following paragraphs describe both methods.
         For additional information, see the bulleted item
         "<link linkend='local-yp-release'>Yocto Project Release</link>".
-    </para>
+    </para> 
 
     <para>
         As mentioned, one way to get the Yocto Project files is to use Git to clone the 
@@ -45,19 +45,26 @@
      $ tar xfj poky-edison-6.0.tar.bz2
      $ cd poky
         </literallayout> 
-        <note>If you're using the tarball method, you can ignore all the following steps that
+        <note><para>If you're using the tarball method, you can ignore all the following steps that
         ask you to carry out Git operations.  
         You already have the results of those operations
         in the form of the edison release tarballs.
         Consequently, there is nothing left to do other than extract those tarballs into the 
-        proper locations.</note>
+        proper locations.</para>
+
+        <para>Once you expand the released tarball, you have a snapshot of the Git repository
+        that represents a specific release.
+        Fundamentally, this is different than having a local copy of the Yocto Project 
+        Git repository.  
+        Given the tarball method, changes you make are building on top of a release, while
+        you are tracking development when you use the Git repository method.</para></note>
     </para>
 
     <para>
-        Once you have the local <filename>poky</filename> Git repository set up, 
+        With the local <filename>poky</filename> Git repository set up, 
         you have all the development branches available to you from which you can work. 
-        However, you need to be sure that your local repository reflects the specific
-        snapshot of the release you are interested in.
+        Next, you need to be sure that your local repository reflects the exact
+        release in which you are interested.
         From inside the repository you can see the development branches that represent
         areas of development that have diverged from the main (master) branch.  
         You can also see the tag names used to mark snapshots of stable releases or 
@@ -70,8 +77,8 @@
         </literallayout> 
         For this example, we are going to use the Yocto Project 1.1 Release, which is code
         named "edison". 
-        To make sure we have a local area (branch in Git terms) on our machine that tracks
-        the snapshot of the 1.1 release, we can use the following commands:
+        To make sure we have a local area (branch in Git terms) on our machine that 
+        reflects the 1.1 release, we can use the following commands:
         <literallayout class='monospaced'>
      $ cd ~/poky
      $ git fetch --tags
@@ -84,10 +91,10 @@
         local repository.
         The Git <filename>checkout</filename> command with the <filename>-b</filename> option
         creates a local branch for you named <filename>edison</filename>.
-        Your local branch tracks the Yocto Project 1.1 released tarball marked with the 
-        <filename>edison-6.0</filename> tag in the source repositories.
+        Your local branch begins in the same state as the Yocto Project 1.1 released tarball 
+        marked with the <filename>edison-6.0</filename> tag in the source repositories.
     </para>
-</section>
+</section> 
 
 <section id='choosing-a-base-bsp-app'>
     <title>Choosing a Base BSP</title>