From 2f1d30ad6564d4f5848778eeba0bbcd0e89a3fb8 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 13 Sep 2011 09:26:49 -0700 Subject: 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 Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-newbie.xml | 28 +++++++++++++------------- 1 file 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 @@ environment might find helpful. Some terms are universal but are included here just in case: - Image - 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. + Image - 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 Reference: Images appendix in @@ -179,7 +178,7 @@ (i.e. Texas Instruments ARM Cortex-A8 development board). Configuration files end with a .conf filename extension. Classes - 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 .bbclass filename extension. Append Files - Files that append build information to @@ -222,17 +221,16 @@ - 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. - - - - You can find information on the MIT License here. - You can find information on the GNU GPL here. + You can find information on the MIT license at + here. + You can find information on the GNU GPL + here. @@ -377,7 +375,7 @@ 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 @@ Make Small Changes - 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. + to more easily include or refuse changes. + It is also good practice to leave the repository in a state that allows you to + still successfully build your project. Use Branches Liberally - It is very easy to create, use, and delete local branches in your working Git repository. You can name these branches anything you like. -- cgit v1.2.3-54-g00ecf