From e2300491980fa3be035f1698b74ce593f27e8ba1 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 28 May 2013 08:40:40 +0300 Subject: dev-manual: Updated wording about Git I removed the statement saying that checking out a Git repository is a backup of the repo. Technically, that is not true. It would be more of a clone operation. The statement was superfluous anyway so I decided to remove it altogether. Reported-by: Trevor Woerner (From yocto-docs rev: 081bd0119f8c17a3932485857b6846dcb6998ee1) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-newbie.xml | 108 ++++++++++++------------- 1 file changed, 54 insertions(+), 54 deletions(-) (limited to 'documentation/dev-manual/dev-manual-newbie.xml') diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 46b680e6be..779d06d57e 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -12,9 +12,9 @@ closed, proprietary environment. Additionally, the Yocto Project uses specific tools and constructs as part of its development environment. - This chapter specifically addresses open source philosophy, using the + This chapter specifically addresses open source philosophy, using the Yocto Project in a team environment, source repositories, Yocto Project - terms, licensing, the open source distributed version control system Git, + terms, licensing, the open source distributed version control system Git, workflows, bug tracking, and how to submit changes. @@ -190,15 +190,15 @@ extensive testing while they continue to develop locally using their primary development system. - Enable the PR Service when package feeds - need to be incremental with continually increasing - PR + Enable the PR Service when package feeds + need to be incremental with continually increasing + PR values. - Typically, this situation occurs when you use or + Typically, this situation occurs when you use or publish package feeds and use a shared state. You should enable the PR Service for all users who use the shared state pool. - For more information on the PR Service, see the + For more information on the PR Service, see the "Working With a PR Service". @@ -218,9 +218,9 @@ Of the SCMs BitBake supports, the Yocto Project team strongly recommends using Git. - Git is a distributed system that is easy to backup - (each checkout is a backup in itself), allows you to work - remotely, and then connects back to the infrastructure. + Git is a distributed system that is easy to backup, + allows you to work remotely, and then connects back to the + infrastructure. For information about BitBake and SCMs, see the BitBake manual located in the @@ -428,8 +428,8 @@ - For any supported release of Yocto Project, you can go to the - Yocto Project Website and + For any supported release of Yocto Project, you can go to the + Yocto Project Website and select the "Downloads" tab and get a tarball of the release. You can also go to this site to download any supported BSP tarballs. Unpacking the tarball gives you a hierarchical Source Directory that lets you develop @@ -461,7 +461,7 @@ - "Downloads" page for the + "Downloads" page for the Yocto Project Website: Access this page by going to the website and then selecting the "Downloads" tab. @@ -489,7 +489,7 @@ Append files are known as BitBake append files and .bbappend files. The OpenEmbedded build system expects every append file to have a corresponding recipe (.bb) file. - Furthermore, the append file and corresponding recipe file + Furthermore, the append file and corresponding recipe file must use the same root filename. The filenames can differ only in the file type suffix used (e.g. formfactor_0.0.bb and formfactor_0.0.bbappend). @@ -641,7 +641,7 @@ OE-Core: A core set of Metadata originating with OpenEmbedded (OE) that is shared between OE and the Yocto Project. - This Metadata is found in the meta directory of the + This Metadata is found in the meta directory of the Source Directory. Package: In the context of the Yocto Project, this term refers to the packaged output from a baked recipe. @@ -776,7 +776,7 @@ When you build an image using the Yocto Project, the build process uses a known list of licenses to ensure compliance. - You can find this list in the + You can find this list in the Source Directory at meta/files/common-licenses. Once the build completes, the list of all licenses found and used during that build are @@ -869,7 +869,7 @@ When you clone a Git repository, you end up with an identical copy of the repository on your development system. Once you have a local copy of a repository, you can take steps to develop locally. - For examples on how to clone Git repositories, see the + For examples on how to clone Git repositories, see the "Getting Set Up" section. @@ -911,14 +911,14 @@ $ cd poky $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; - In this example, the name of the top-level directory of your local - Source Directory + In this example, the name of the top-level directory of your local + Source Directory is poky, - and the name of that local working area (local branch) you just + and the name of that local working area (local branch) you just created and checked out is &DISTRO_NAME;. - The files in your local repository now reflect the same files that - are in the &DISTRO_NAME; development - branch of the Yocto Project's poky + The files in your local repository now reflect the same files that + are in the &DISTRO_NAME; development + branch of the Yocto Project's poky upstream repository. It is important to understand that when you create and checkout a local working branch based on a branch name, @@ -1037,10 +1037,10 @@ repository and places it in your local Git repository. You use this command to make sure you are synchronized with the repository from which you are basing changes (.e.g. the master branch). - git push: - Sends all your committed local changes to an upstream Git + git push: + Sends all your committed local changes to an upstream Git repository (e.g. a contribution repository). - The maintainer of the project draws from these repositories + The maintainer of the project draws from these repositories when adding changes to the project’s master repository or other development branch. @@ -1088,8 +1088,8 @@ 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 organizing the underlying branch structure to reflect release strategies and so forth. - For information on finding out who is responsible (maintains) - for a particular area of code, see the + For information on finding out who is responsible (maintains) + for a particular area of code, see the "How to Submit a Change" section. @@ -1160,8 +1160,8 @@ You can name these branches anything you like. It is helpful to give them names associated with the particular feature or change on which you are working. - Once you are done with a feature or change and have merged it - into your local master branch, simply discard the temporary + Once you are done with a feature or change and have merged it + into your local master branch, simply discard the temporary branch. Merge Changes: The git merge command allows you to take the @@ -1189,9 +1189,9 @@ send-pull-request that ship with the release to facilitate this workflow. You can find these scripts in the scripts - folder of the + folder of the Source Directory. - For information on how to use these scripts, see the + For information on how to use these scripts, see the "Using Scripts to Push a Change Upstream and Request a Pull" section. Patch Workflow: This workflow allows you to notify the @@ -1199,7 +1199,7 @@ for the "master" branch of the Git repository. To send this type of change, you format the patch and then send the email using the Git commands git format-patch and git send-email. - For information on how to use these scripts, see the + For information on how to use these scripts, see the "How to Submit a Change" section. @@ -1251,10 +1251,10 @@ Provide a detailed description of the issue. You should provide as much detail as you can about the context, behavior, output, and so forth that surrounds the issue. - You can even attach supporting files for output from logs by + You can even attach supporting files for output from logs by using the "Add an attachment" button. - Be sure to copy the appropriate people in the - "CC List" for the bug. + Be sure to copy the appropriate people in the + "CC List" for the bug. See the "How to Submit a Change" section for information about finding out who is responsible for code. @@ -1281,37 +1281,37 @@ or notifying: Maintenance File: - Examine the maintainers.inc file, which is - located in the + Examine the maintainers.inc file, which is + located in the Source Directory - at meta-yocto/conf/distro/include, to + at meta-yocto/conf/distro/include, to see who is responsible for code. Board Support Package (BSP) README Files: - For BSP maintainers of supported BSPs, you can examine + For BSP maintainers of supported BSPs, you can examine individual BSP README files. - Alternatively, you can examine the - MAINTAINERS file, which is found in the + Alternatively, you can examine the + MAINTAINERS file, which is found in the meta-intel, for a list of all supported BSP maintainers. Search by File: - Using Git, you can enter the - following command to bring up a short list of all commits + Using Git, you can enter the + following command to bring up a short list of all commits against a specific file: git shortlog -- <filename> Just provide the name of the file for which you are interested. - The information returned is not ordered by history but does - include a list of all committers grouped by name. + The information returned is not ordered by history but does + include a list of all committers grouped by name. From the list, you can see who is responsible for the bulk of the changes against the file. - + For a list of the Yocto Project and related mailing lists, see the "Mailing lists" section in the Yocto Project Reference Manual. @@ -1320,7 +1320,7 @@ Here is some guidance on which mailing list to use for what type of change: - For changes to the core + For changes to the core Metadata, send your patch to the openembedded-core mailing list. For example, a change to anything under the meta or @@ -1435,7 +1435,7 @@ - The next two sections describe general instructions for both pushing + The next two sections describe general instructions for both pushing changes upstream and for submitting changes as patches. @@ -1493,7 +1493,7 @@ Depending on the components changed, you need to submit the email to a specific mailing list. For some guidance on which mailing list to use, see the list in the - "How to Submit a Change" + "How to Submit a Change" section. For a description of the available mailing lists, see the "Mailing Lists" @@ -1521,8 +1521,8 @@ To format commits, use the git format-patch command. When you provide the command, you must include a revision list or a number of patches as part of the command. - For example, either of these two commands takes your most - recent single commit and formats it as an email message in + For example, either of these two commands takes your most + recent single commit and formats it as an email message in the current directory: $ git format-patch -1 @@ -1534,7 +1534,7 @@ After the command is run, the current directory contains a numbered .patch file for the commit. If you provide several commits as part of the command, - the git format-patch command produces a + the git format-patch command produces a series of numbered files in the current directory – one for each commit. If you have more than one patch, you should also use the --cover option with the command, which generates a @@ -1571,7 +1571,7 @@ The command also has several options that let you specify recipients and perform further editing of the email message. For information on how to use the git send-email command, - see GIT-SEND-EMAIL(1) displayed using + see GIT-SEND-EMAIL(1) displayed using the man git-send-email command. -- cgit v1.2.3-54-g00ecf