From f7d2cea75598fbcd49dc900d5bea7eec668f6302 Mon Sep 17 00:00:00 2001
From: Scott Rifenbark <scott.m.rifenbark@intel.com>
Date: Fri, 15 Feb 2013 13:05:30 -0600
Subject: dev-manual: Review comments added to "Working in Team" section

Fixes YOCTO #3274

Applied several recommended changes for the section describing
best practices when using YP in a team enviornment.  these
changes were from Dave Stewart.

(From yocto-docs rev: 7efc9864dc6757e3cf5c026f3c1785e5947cbfec)

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 | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

(limited to 'documentation/dev-manual/dev-manual-newbie.xml')

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index abf0890d65..4d99e39530 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -79,8 +79,8 @@
 
         <para>
             Systems across a large team should meet the needs of
-            two types of developers: those working on the direction of the
-            software stack itself and those developing applications.
+            two types of developers: those working on the contents of the
+            operating system image itself and those developing applications.
             Regardless of the type of developer, their workstations must
             be both reasonably powerful and run Linux.
         </para>
@@ -131,8 +131,11 @@
                 build system itself available on the developer workstations
                 so developers can run their own builds and directly
                 rebuild the software stack.
-                You should keep the core system standard as much as
+                You should keep the core system unchanged as much as
                 possible and do your work in layers on top of the core system.
+                Doing so gives you a greater level of portability when
+                upgrading to new versions of the core system or Board
+                Support Packages (BSPs).
                 You can share layers amongst the developers of a particular
                 project and contain the policy configuration that defines
                 the project.
@@ -357,14 +360,17 @@
                     Git repositories.</para></listitem>
                 <listitem><para>Set up the directory for the shared state cache
                     (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
-                    where they make sense.
-                    For example, set up the sstate cache for developers using the
-                    same office and share source directories on the developer's
-                    machines.</para></listitem>
+                    where it makes sense.
+                    For example, set up the sstate cache on a system used
+                    by developers that share the same office and share the
+                    same source directories on their machines.
+                    </para></listitem>
                 <listitem><para>Set up an autobuilder and have it populate the
                     sstate cache and source directories.</para></listitem>
-                <listitem><para>Follow the project commit guidelines for
-                    writing good commit messages.
+                <listitem><para>The Yocto Project community encourages you
+                    to send patches to the project to fix bugs or add features.
+                    If you do submit patches, follow the project commit
+                    guidelines for writing good commit messages.
                     See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
                     section.</para></listitem>
                 <listitem><para>Send changes to the core sooner than later
-- 
cgit v1.2.3-54-g00ecf