documentation/dev-manual/dev-manual-newbie.xml: Updates from Robert Berger

Added some clarification on the ability for testing.  The wording as
it was implied that the YP provided a complete testing framework,
which is not true.

(From yocto-docs rev: e40b39179c69b69f012f231009131b1efa7e732b)

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

documentation/dev-manual/dev-manual-newbie.xml

@@ -132,11 +132,10 @@
         environment might find helpful.
         Some terms are universal but are included here just in case:
     <itemizedlist>
-        <listitem><para><emphasis>Image</emphasis> - An image is a collection of recipes created
+        <listitem><para><emphasis>Image</emphasis> - An image is the result produced when 
-            with BitBake (baked) and made part of a root filesystem.
+            BitBake processes a given collection of recipes and related metadata.
-            Images are both the binary output that runs on specific hardware and for specific
+            Images are the binary output that runs on specific hardware and for specific
-            use cases as well as a metadata recipe that BitBake processes to generate the 
+            use cases.
-            binary output.
             For a list of the supported image types that the Yocto Project provides, see the
             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
             Reference: Images</ulink> appendix in
@@ -179,7 +178,7 @@
             (i.e. Texas Instruments ARM Cortex-A8 development board).  
             Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
         <listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation
-            and inheritance allowing commonly used pattrerns to be defined once and easily used 
+            and inheritance allowing commonly used patterns to be defined once and easily used 
             in multiple recipes.  
             Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
         <listitem><para><emphasis>Append Files</emphasis> - Files that append build information to 
@@ -222,17 +221,16 @@
     </para>
 
     <para>
-        In general, Yocto Project is broadly licensed under the Massachusetts Institute of Technology 
+        In general, the Yocto Project is broadly licensed under the Massachusetts Institute of Technology 
         (MIT) License.  
         MIT licensing permits the reuse of software within proprietary software as long as the 
         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.
-    </para>
+        You can find information on the MIT license at  
-
+        <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>.
-    <para>
+        You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>
-        You can find information on the MIT License <ulink url='http://en.wikipedia.org/wiki/MIT_License'>here</ulink>.
+        here</ulink>. 
-        You can find information on the GNU GPL <ulink url='http://en.wikipedia.org/wiki/GPL'>here</ulink>. 
     </para>
 
     <para>
@@ -377,7 +375,7 @@
     <para>
         The Yocto Project files are maintained using Git in a "master" branch whose Git history 
         tracks every change and whose structure provides branches for all diverging functionality.
-        This is typical for open-source projects, although Git does not have to be used.
+        Although there is no need to use Git, This practice is typical for open-source projects.
         For the Yocto Project a key individual called the "maintainer" is responsible for "master".  
         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 
@@ -436,7 +434,9 @@
         <listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit 
             small as compared to bundling many disparate changes into a single commit.  
             This practice not only keeps things manageable but also allows the maintainer 
-            to more easily include or refuse changes.</para></listitem>
+            to more easily include or refuse changes.</para>
+            <para>It is also good practice to leave the repository in a state that allows you to 
+            still successfully build your project.</para></listitem>
         <listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and 
             delete local branches in your working Git repository.  
             You can name these branches anything you like.