diff options
| -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 |
