summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2013-02-15 13:05:30 -0600
committerRichard Purdie <richard.purdie@linuxfoundation.org>2013-03-02 12:57:21 +0000
commitf7d2cea75598fbcd49dc900d5bea7eec668f6302 (patch)
tree601bf170efb9fdf10e7670d6f7c70b87a231f160
parent63788f1f666f59ff9c4c56c9f28ac94a45ec9bf6 (diff)
downloadpoky-f7d2cea75598fbcd49dc900d5bea7eec668f6302.tar.gz
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>
-rw-r--r--documentation/dev-manual/dev-manual-newbie.xml24
1 files changed, 15 insertions, 9 deletions
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 @@
79 79
80 <para> 80 <para>
81 Systems across a large team should meet the needs of 81 Systems across a large team should meet the needs of
82 two types of developers: those working on the direction of the 82 two types of developers: those working on the contents of the
83 software stack itself and those developing applications. 83 operating system image itself and those developing applications.
84 Regardless of the type of developer, their workstations must 84 Regardless of the type of developer, their workstations must
85 be both reasonably powerful and run Linux. 85 be both reasonably powerful and run Linux.
86 </para> 86 </para>
@@ -131,8 +131,11 @@
131 build system itself available on the developer workstations 131 build system itself available on the developer workstations
132 so developers can run their own builds and directly 132 so developers can run their own builds and directly
133 rebuild the software stack. 133 rebuild the software stack.
134 You should keep the core system standard as much as 134 You should keep the core system unchanged as much as
135 possible and do your work in layers on top of the core system. 135 possible and do your work in layers on top of the core system.
136 Doing so gives you a greater level of portability when
137 upgrading to new versions of the core system or Board
138 Support Packages (BSPs).
136 You can share layers amongst the developers of a particular 139 You can share layers amongst the developers of a particular
137 project and contain the policy configuration that defines 140 project and contain the policy configuration that defines
138 the project. 141 the project.
@@ -357,14 +360,17 @@
357 Git repositories.</para></listitem> 360 Git repositories.</para></listitem>
358 <listitem><para>Set up the directory for the shared state cache 361 <listitem><para>Set up the directory for the shared state cache
359 (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>) 362 (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
360 where they make sense. 363 where it makes sense.
361 For example, set up the sstate cache for developers using the 364 For example, set up the sstate cache on a system used
362 same office and share source directories on the developer's 365 by developers that share the same office and share the
363 machines.</para></listitem> 366 same source directories on their machines.
367 </para></listitem>
364 <listitem><para>Set up an autobuilder and have it populate the 368 <listitem><para>Set up an autobuilder and have it populate the
365 sstate cache and source directories.</para></listitem> 369 sstate cache and source directories.</para></listitem>
366 <listitem><para>Follow the project commit guidelines for 370 <listitem><para>The Yocto Project community encourages you
367 writing good commit messages. 371 to send patches to the project to fix bugs or add features.
372 If you do submit patches, follow the project commit
373 guidelines for writing good commit messages.
368 See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" 374 See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
369 section.</para></listitem> 375 section.</para></listitem>
370 <listitem><para>Send changes to the core sooner than later 376 <listitem><para>Send changes to the core sooner than later