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

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 <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2011-07-22 10:11:46 -07:00 committed by Richard Purdie
parent c6a7a82a9c
commit 70b317ecce
1 changed files with 20 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -344,27 +344,30 @@
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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 @@
<para>
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.”
</para>
<para>
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.</para></listitem>
<listitem><para><emphasis>Merge Changes</emphasis> - The Git merge command allows you to take the
<listitem><para><emphasis>Merge Changes</emphasis> - The <filename>git merge</filename>
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.</para></listitem>
<listitem><para><emphasis>Manage Branches</emphasis> - 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.</para></listitem>
<listitem><para><emphasis>Patch Workflow</emphasis> - 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
<filename>git format-patch</filename> and <filename>git send-email</filename>.
You can find information on how to submit later in this chapter.</para></listitem>
@ -441,7 +445,7 @@
<title>Tracking Bugs</title>
<para>
The Yocto Project uses Bugzilla to track bugs.
The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> 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.