diff options
| author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2013-02-15 13:05:30 -0600 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2013-03-02 12:57:21 +0000 |
| commit | f7d2cea75598fbcd49dc900d5bea7eec668f6302 (patch) | |
| tree | 601bf170efb9fdf10e7670d6f7c70b87a231f160 /documentation | |
| parent | 63788f1f666f59ff9c4c56c9f28ac94a45ec9bf6 (diff) | |
| download | ast2050-yocto-poky-f7d2cea75598fbcd49dc900d5bea7eec668f6302.zip ast2050-yocto-poky-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>
Diffstat (limited to 'documentation')
| -rw-r--r-- | documentation/dev-manual/dev-manual-newbie.xml | 24 |
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 abf0890..4d99e39 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 |
