1
0
mirror of https://git.yoctoproject.org/poky synced 2026-05-09 05:29:32 +00:00

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>
This commit is contained in:
Scott Rifenbark
2013-02-15 13:05:30 -06:00
committed by Richard Purdie
parent 63788f1f66
commit f7d2cea755
+15 -9
View File
@@ -79,8 +79,8 @@
<para> <para>
Systems across a large team should meet the needs of Systems across a large team should meet the needs of
two types of developers: those working on the direction of the two types of developers: those working on the contents of the
software stack itself and those developing applications. operating system image itself and those developing applications.
Regardless of the type of developer, their workstations must Regardless of the type of developer, their workstations must
be both reasonably powerful and run Linux. be both reasonably powerful and run Linux.
</para> </para>
@@ -131,8 +131,11 @@
build system itself available on the developer workstations build system itself available on the developer workstations
so developers can run their own builds and directly so developers can run their own builds and directly
rebuild the software stack. 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. 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 You can share layers amongst the developers of a particular
project and contain the policy configuration that defines project and contain the policy configuration that defines
the project. the project.
@@ -357,14 +360,17 @@
Git repositories.</para></listitem> Git repositories.</para></listitem>
<listitem><para>Set up the directory for the shared state cache <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>) (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
where they make sense. where it makes sense.
For example, set up the sstate cache for developers using the For example, set up the sstate cache on a system used
same office and share source directories on the developer's by developers that share the same office and share the
machines.</para></listitem> same source directories on their machines.
</para></listitem>
<listitem><para>Set up an autobuilder and have it populate the <listitem><para>Set up an autobuilder and have it populate the
sstate cache and source directories.</para></listitem> sstate cache and source directories.</para></listitem>
<listitem><para>Follow the project commit guidelines for <listitem><para>The Yocto Project community encourages you
writing good commit messages. 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>" See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section.</para></listitem> section.</para></listitem>
<listitem><para>Send changes to the core sooner than later <listitem><para>Send changes to the core sooner than later