sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

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>
This commit is contained in:
Scott Rifenbark 2011-09-13 09:26:49 -07:00 committed by Richard Purdie
parent dab5ffcf46
commit 2f1d30ad65
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
documentation/dev-manual/dev-manual-newbie.xml
View File

@ -132,11 +132,10 @@
environment might find helpful.
Some terms are universal but are included here just in case:
<itemizedlist>
<listitem><para><emphasis>Image</emphasis> - An image is a collection of recipes created
with BitBake (baked) and made part of a root filesystem.
Images are both the binary output that runs on specific hardware and for specific
use cases as well as a metadata recipe that BitBake processes to generate the
binary output.
<listitem><para><emphasis>Image</emphasis> - An image is the result produced when
BitBake processes a given collection of recipes and related metadata.
Images are the binary output that runs on specific hardware and for specific
use cases.
For a list of the supported image types that the Yocto Project provides, see the
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
Reference: Images</ulink> appendix in
@ -179,7 +178,7 @@
(i.e. Texas Instruments ARM Cortex-A8 development board).
Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
<listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation
and inheritance allowing commonly used pattrerns to be defined once and easily used
and inheritance allowing commonly used patterns to be defined once and easily used
in multiple recipes.
Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
<listitem><para><emphasis>Append Files</emphasis> - Files that append build information to
@ -222,17 +221,16 @@
</para>
<para>
In general, Yocto Project is broadly licensed under the Massachusetts Institute of Technology
In general, the Yocto Project is broadly licensed under the Massachusetts Institute of Technology
(MIT) License.
MIT licensing permits the reuse of software within proprietary software as long as the
license is distributed with that software.
MIT is also compatible with the GNU General Public License (GPL).
Patches to the Yocto Project follow the upstream licensing scheme.
</para>
<para>
You can find information on the MIT License <ulink url='http://en.wikipedia.org/wiki/MIT_License'>here</ulink>.
You can find information on the GNU GPL <ulink url='http://en.wikipedia.org/wiki/GPL'>here</ulink>.
You can find information on the MIT license at
<ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>.
You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>
here</ulink>.
</para>
<para>
@ -377,7 +375,7 @@
<para>
The Yocto Project files are maintained using Git in a "master" branch whose Git history
tracks every change and whose structure provides branches for all diverging functionality.
This is typical for open-source projects, although Git does not have to be used.
Although there is no need to use Git, This practice is typical for open-source projects.
For the Yocto Project a key individual called the "maintainer" is responsible for "master".
The "master" branch is the “upstream” repository where the final builds of the project occur.
The maintainer is responsible for allowing changes in from other developers and for
@ -436,7 +434,9 @@
<listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit
small as compared to bundling many disparate changes into a single commit.
This practice not only keeps things manageable but also allows the maintainer
to more easily include or refuse changes.</para></listitem>
to more easily include or refuse changes.</para>
<para>It is also good practice to leave the repository in a state that allows you to
still successfully build your project.</para></listitem>
<listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and
delete local branches in your working Git repository.
You can name these branches anything you like.