summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual/dev-manual-newbie.xml
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2011-09-13 09:26:49 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-09-13 21:48:38 +0100
commit2f1d30ad6564d4f5848778eeba0bbcd0e89a3fb8 (patch)
tree548dba251e42cba6eacbc21f8ddede42dad81dcf /documentation/dev-manual/dev-manual-newbie.xml
parentdab5ffcf465232f77f1155905d9757b8c00da3b0 (diff)
downloadpoky-2f1d30ad6564d4f5848778eeba0bbcd0e89a3fb8.tar.gz
documentation/dev-manual/dev-manual-newbie.xml: Updates from Robert Berger
Added some clarification on the ability for testing. The wording as it was implied that the YP provided a complete testing framework, which is not true. (From yocto-docs rev: e40b39179c69b69f012f231009131b1efa7e732b) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual/dev-manual-newbie.xml')
-rw-r--r--documentation/dev-manual/dev-manual-newbie.xml28
1 files changed, 14 insertions, 14 deletions
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 14f5ca1b56..dc706dd8ff 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -132,11 +132,10 @@
132 environment might find helpful. 132 environment might find helpful.
133 Some terms are universal but are included here just in case: 133 Some terms are universal but are included here just in case:
134 <itemizedlist> 134 <itemizedlist>
135 <listitem><para><emphasis>Image</emphasis> - An image is a collection of recipes created 135 <listitem><para><emphasis>Image</emphasis> - An image is the result produced when
136 with BitBake (baked) and made part of a root filesystem. 136 BitBake processes a given collection of recipes and related metadata.
137 Images are both the binary output that runs on specific hardware and for specific 137 Images are the binary output that runs on specific hardware and for specific
138 use cases as well as a metadata recipe that BitBake processes to generate the 138 use cases.
139 binary output.
140 For a list of the supported image types that the Yocto Project provides, see the 139 For a list of the supported image types that the Yocto Project provides, see the
141 <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'> 140 <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
142 Reference: Images</ulink> appendix in 141 Reference: Images</ulink> appendix in
@@ -179,7 +178,7 @@
179 (i.e. Texas Instruments ARM Cortex-A8 development board). 178 (i.e. Texas Instruments ARM Cortex-A8 development board).
180 Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem> 179 Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
181 <listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation 180 <listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation
182 and inheritance allowing commonly used pattrerns to be defined once and easily used 181 and inheritance allowing commonly used patterns to be defined once and easily used
183 in multiple recipes. 182 in multiple recipes.
184 Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem> 183 Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
185 <listitem><para><emphasis>Append Files</emphasis> - Files that append build information to 184 <listitem><para><emphasis>Append Files</emphasis> - Files that append build information to
@@ -222,17 +221,16 @@
222 </para> 221 </para>
223 222
224 <para> 223 <para>
225 In general, Yocto Project is broadly licensed under the Massachusetts Institute of Technology 224 In general, the Yocto Project is broadly licensed under the Massachusetts Institute of Technology
226 (MIT) License. 225 (MIT) License.
227 MIT licensing permits the reuse of software within proprietary software as long as the 226 MIT licensing permits the reuse of software within proprietary software as long as the
228 license is distributed with that software. 227 license is distributed with that software.
229 MIT is also compatible with the GNU General Public License (GPL). 228 MIT is also compatible with the GNU General Public License (GPL).
230 Patches to the Yocto Project follow the upstream licensing scheme. 229 Patches to the Yocto Project follow the upstream licensing scheme.
231 </para> 230 You can find information on the MIT license at
232 231 <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>.
233 <para> 232 You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>
234 You can find information on the MIT License <ulink url='http://en.wikipedia.org/wiki/MIT_License'>here</ulink>. 233 here</ulink>.
235 You can find information on the GNU GPL <ulink url='http://en.wikipedia.org/wiki/GPL'>here</ulink>.
236 </para> 234 </para>
237 235
238 <para> 236 <para>
@@ -377,7 +375,7 @@
377 <para> 375 <para>
378 The Yocto Project files are maintained using Git in a "master" branch whose Git history 376 The Yocto Project files are maintained using Git in a "master" branch whose Git history
379 tracks every change and whose structure provides branches for all diverging functionality. 377 tracks every change and whose structure provides branches for all diverging functionality.
380 This is typical for open-source projects, although Git does not have to be used. 378 Although there is no need to use Git, This practice is typical for open-source projects.
381 For the Yocto Project a key individual called the "maintainer" is responsible for "master". 379 For the Yocto Project a key individual called the "maintainer" is responsible for "master".
382 The "master" branch is the “upstream” repository where the final builds of the project occur. 380 The "master" branch is the “upstream” repository where the final builds of the project occur.
383 The maintainer is responsible for allowing changes in from other developers and for 381 The maintainer is responsible for allowing changes in from other developers and for
@@ -436,7 +434,9 @@
436 <listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit 434 <listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit
437 small as compared to bundling many disparate changes into a single commit. 435 small as compared to bundling many disparate changes into a single commit.
438 This practice not only keeps things manageable but also allows the maintainer 436 This practice not only keeps things manageable but also allows the maintainer
439 to more easily include or refuse changes.</para></listitem> 437 to more easily include or refuse changes.</para>
438 <para>It is also good practice to leave the repository in a state that allows you to
439 still successfully build your project.</para></listitem>
440 <listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and 440 <listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and
441 delete local branches in your working Git repository. 441 delete local branches in your working Git repository.
442 You can name these branches anything you like. 442 You can name these branches anything you like.