From 70b317ecce3df883c8edd7298a1dc8239a4c9fd4 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 22 Jul 2011 10:11:46 -0700 Subject: documentation/dev-manual/dev-manual-newbie.xml: edits to workflow General edits to the workflow section. Also created a link to to Bugzilla in the next section. (From yocto-docs rev: 2e70b19d24bb4649fb525232fca9ab2e01c5ec61) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-newbie.xml | 36 ++++++++++++++------------ 1 file changed, 20 insertions(+), 16 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 fbd12946e1..f1557aa396 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -344,27 +344,30 @@ - A master Git repository exists that contains the project. - Usually a key individual is responsible for this repository. - It is the “upstream” repository where the final builds of the project occur. + 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. + For the Yocto Project a key individual 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 - organizing the branch structure of the repository to reflect release strategies and so forth. + organizing the underlying branch structure to reflect release strategies and so forth. The maintainer of the project also owns a contribution repository usually known as a “contrib” area. The contrib area temporarily holds changes to the project that have been submitted or committed - by the development team. - The maintainer determines if the changes are qualified to be moved into the master repository. + by the Yocto Project development team and by community members that contribute to the project. + The maintainer determines if the changes are qualified to be moved into the "master" branch + of the Git repository. - Developers create and maintain cloned repositories of the upstream master repository. + Developers (including contributing community members) create and maintain cloned repositories + of the upstream "master" branch. These repositories are local to their development platforms and are used to develop changes. When a developer is satisfied with a particular feature or change they “push” the changes - up to the contrib repository. - Developers are responsible for keeping their local repository up-to-date with the master - repository. + up to the "contrib" repository. + Developers are responsible for keeping their local repository up-to-date with "master". They are also responsible for straightening out any conflicts that might arise within files that are being worked on simultaneously by more than one person. All this work is done locally on the developer’s machine before anything is pushed upstream @@ -373,13 +376,13 @@ A somewhat formal method exists by which developers commit changes and push them into the - contrib area and subsequently request that the maintainer include them into the master repository. + "contrib" area and subsequently request that the maintainer include them into "master" This process is called “submitting a patch” or “submitting a change.” To summarize the environment: we have a single point of entry for changes into the project’s - master repository, which is controlled by the project’s maintainer. + "master" branch of the Git repository, which is controlled by the project’s maintainer. And, we have a set of developers who independently develop, test, and submit changes upstream for the maintainer to examine. The maintainer then chooses which changes are going to become permanently a part of the project. @@ -406,12 +409,13 @@ 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 you simply discard the branch. - Merge Changes - The Git merge command allows you to take the + Merge Changes - The git merge + command allows you to take the changes from one branch and fold them into another branch. This process is especially helpful when more than a single developer might be working on different parts of the same feature. Merging changes also automatically identifies any collisions or “conflicts” - that might happen resulting from the same lines of code be altered by two different + that might happen resulting from the same lines of code being altered by two different developers. Manage Branches - Because branches are easy to use, you should use a system where branches indicate varying levels of code readiness. @@ -429,7 +433,7 @@ on which to develop. Patch Workflow - This workflow allows you to notify the maintainer through an email that you have a change (or patch) you would like considered - for the master repository. + 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. You can find information on how to submit later in this chapter. @@ -441,7 +445,7 @@ Tracking Bugs - The Yocto Project uses Bugzilla to track bugs. + The Yocto Project uses Bugzilla to track bugs. This bug-tracking application works well for group development because it tracks bugs and code changes, can be used to communicate changes and problems with developers, can be used to submit and review patches, and can be used to manage quality assurance. -- cgit v1.2.3-54-g00ecf