documentation/dev-manual/dev-manual-newbie.xml: edits to workflow

General edits to the workflow section.  Also created a link to
to Bugzilla in the next section.

(From yocto-docs rev: 2e70b19d24bb4649fb525232fca9ab2e01c5ec61)

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

1 files changed, 20 insertions, 16 deletions

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index fbd12946e1..f1557aa396 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -344,27 +344,30 @@
     </para>
 
     <para>
-        A master Git repository exists that contains the project.  
-        Usually a key individual is responsible for this repository.  
-        It is the “upstream” repository where the final builds of the project occur.  
+        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.
+        For the Yocto Project a key individual 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 
-        organizing the branch structure of the repository to reflect release strategies and so forth.  
+        organizing the underlying branch structure to reflect release strategies and so forth.  
     </para>
 
     <para>
         The maintainer of the project also owns a contribution repository usually known as a “contrib” area.  
         The contrib area temporarily holds changes to the project that have been submitted or committed 
-        by the development team.  
-        The maintainer determines if the changes are qualified to be moved into the master repository.
+        by the Yocto Project development team and by community members that contribute to the project.  
+        The maintainer determines if the changes are qualified to be moved into the "master" branch
+        of the Git repository.
     </para>
 
     <para>
-        Developers create and maintain cloned repositories of the upstream master repository.  
+        Developers (including contributing community members) create and maintain cloned repositories 
+        of the upstream "master" branch.  
         These repositories are local to their development platforms and are used to develop changes.  
         When a developer is satisfied with a particular feature or change they “push” the changes 
-        up to the contrib repository.  
-        Developers are responsible for keeping their local repository up-to-date with the master 
-        repository.  
+        up to the "contrib" repository.  
+        Developers are responsible for keeping their local repository up-to-date with "master".  
         They are also responsible for straightening out any conflicts that might arise within files 
         that are being worked on simultaneously by more than one person.  
         All this work is done locally on the developer’s machine before anything is pushed upstream 
@@ -373,13 +376,13 @@
 
     <para>
         A somewhat formal method exists by which developers commit changes and push them into the 
-        contrib area and subsequently request that the maintainer include them into the master repository.  
+        "contrib" area and subsequently request that the maintainer include them into "master"  
         This process is called “submitting a patch” or “submitting a change.”  
     </para>
 
     <para>
         To summarize the environment:  we have a single point of entry for changes into the project’s 
-        master repository, which is controlled by the project’s maintainer.  
+        "master" branch of the Git repository, which is controlled by the project’s maintainer.  
         And, we have a set of developers who independently develop, test, and submit changes 
         upstream for the maintainer to examine.  
         The maintainer then chooses which changes are going to become permanently a part of the project.  
@@ -406,12 +409,13 @@
             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 you simply discard the branch.</para></listitem>
-        <listitem><para><emphasis>Merge Changes</emphasis> - The Git merge command allows you to take the 
+        <listitem><para><emphasis>Merge Changes</emphasis> - The <filename>git merge</filename>
+            command allows you to take the 
             changes from one branch and fold them into another branch.  
             This process is especially helpful when more than a single developer might be working 
             on different parts of the same feature.  
             Merging changes also automatically identifies any collisions or “conflicts” 
-            that might happen resulting from the same lines of code be altered by two different 
+            that might happen resulting from the same lines of code being altered by two different 
             developers.</para></listitem>
         <listitem><para><emphasis>Manage Branches</emphasis> - Because branches are easy to use, you should 
             use a system where branches indicate varying levels of code readiness.  
@@ -429,7 +433,7 @@
             on which to develop.</para></listitem>
         <listitem><para><emphasis>Patch Workflow</emphasis> - This workflow allows you to notify the 
             maintainer through an email that you have a change (or patch) you would like considered 
-            for the master repository.  
+            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 
             <filename>git format-patch</filename> and <filename>git send-email</filename>. 
             You can find information on how to submit later in this chapter.</para></listitem>
@@ -441,7 +445,7 @@
     <title>Tracking Bugs</title>
 
     <para>
-        The Yocto Project uses Bugzilla to track bugs.  
+        The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
         This bug-tracking application works well for group development because it tracks bugs and code 
         changes, can be used to communicate changes and problems with developers, can be used to 
         submit and review patches, and can be used to manage quality assurance.