diff options
| author |   Scott Rifenbark <scott.m.rifenbark@intel.com> | 2012-11-27 12:44:39 -0600 |
|---|---|---|
| committer |   Richard Purdie <richard.purdie@linuxfoundation.org> | 2012-12-03 13:53:00 +0000 |
| commit | 7c88384bb2349359a4753b424cd18e7dfdd6a870 (patch) | |
| tree | 007e8895f9e8317f5d77680bf4420af16a72da6c /documentation | |
| parent | 518efae890f78f7f446b743c3860fb4f84fb6052 (diff) | |
| download | openembedded-core-contrib-7c88384bb2349359a4753b424cd18e7dfdd6a870.tar.gz | |
documentation: dev-manual - Updated collaboration section
Fixes [YOCTO #3274]
I have added a new area at the bottom of the current
"Using the Yocto Project in a Team Environment" section.
This section is the spot for addressing what Richard Purdie
coined as "How to use YP in a work group." For now, the
changes are based on the information that Richard placed in
the Bugzilla entry. Presumably we can build on this information.
(From yocto-docs rev: 92c5d1b6ac6b553fab19410170364dca40123c59)
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 | 38 |
1 files changed, 36 insertions, 2 deletions
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 37f705b0ee..76d4180c47 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -75,8 +75,8 @@ Experience shows that buildbot is a good fit for this role. What works well is to configure buildbot to make two types of builds: incremental and full (from scratch). - See <ulink url='http://autobuilder.yoctoproject.org:8010/'>Welcome to the buildbot for the - Yocto Project</ulink> for an example implementation that uses buildbot. + See "<ulink url='http://autobuilder.yoctoproject.org:8010/'>Welcome to the buildbot for the Yocto Project</ulink>" + for an example implementation that uses buildbot. </para> <para> @@ -117,6 +117,40 @@ force any particular policy on users, unlike a lot of build systems. The system allows the best policies to be chosen for the given circumstances. </para> + + <para> + In general, best practices exist that make your work with the Yocto + Project easier in a team environment. + This list presents some of these practices you might consider following. + Of course, you need to understand that you do not have to follow these + practices and your setup can be totally controlled and customized by + your team: + <itemizedlist> + <listitem><para>Use <link linkend='git'>Git</link> + as the source control system.</para></listitem> + <listitem><para>Maintain your metadata in layers that make sense + for your situation. + See the "<link linkend='understanding-and-creating-layers'>Understanding + and Creating Layeres</link>" section for more information on + layers.</para></listitem> + <listitem><para>Separate the project's metadata and code by using + separate Git repositories. + See the "<link linkend='yocto-project-repositories'>Yocto Project + Source Repositories</link>" section for information on these + repositories. + See the "<link linkend='getting-setup'>Getting Set Up</link>" section + for information on how to set up various Yocto Project related + 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> + <listitem><para>Set up an autobuilder and have it populate the + sstate cache and source directories.</para></listitem> + </itemizedlist> + </para> </section> <section id='yocto-project-repositories'> |