summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2011-07-22 10:11:46 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-08-04 15:06:42 +0100
commit70b317ecce3df883c8edd7298a1dc8239a4c9fd4 (patch)
tree97dda9c124d73fc7c5a05a679aaaea1f0bb60be0 /documentation
parentc6a7a82a9c11177fc564aa6b29b1473a781e52be (diff)
downloadpoky-70b317ecce3df883c8edd7298a1dc8239a4c9fd4.tar.gz
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>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/dev-manual/dev-manual-newbie.xml36
1 files changed, 20 insertions, 16 deletions
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 @@
344 </para> 344 </para>
345 345
346 <para> 346 <para>
347 A master Git repository exists that contains the project. 347 The Yocto Project files are maintained using Git in a "master" branch whose Git history
348 Usually a key individual is responsible for this repository. 348 tracks every change and whose structure provides branches for all diverging functionality.
349 It is the “upstream” repository where the final builds of the project occur. 349 This is typical for open-source projects, although Git does not have to be used.
350 For the Yocto Project a key individual is responsible for "master".
351 The "master" branch is the “upstream” repository where the final builds of the project occur.
350 The maintainer is responsible for allowing changes in from other developers and for 352 The maintainer is responsible for allowing changes in from other developers and for
351 organizing the branch structure of the repository to reflect release strategies and so forth. 353 organizing the underlying branch structure to reflect release strategies and so forth.
352 </para> 354 </para>
353 355
354 <para> 356 <para>
355 The maintainer of the project also owns a contribution repository usually known as a “contrib” area. 357 The maintainer of the project also owns a contribution repository usually known as a “contrib” area.
356 The contrib area temporarily holds changes to the project that have been submitted or committed 358 The contrib area temporarily holds changes to the project that have been submitted or committed
357 by the development team. 359 by the Yocto Project development team and by community members that contribute to the project.
358 The maintainer determines if the changes are qualified to be moved into the master repository. 360 The maintainer determines if the changes are qualified to be moved into the "master" branch
361 of the Git repository.
359 </para> 362 </para>
360 363
361 <para> 364 <para>
362 Developers create and maintain cloned repositories of the upstream master repository. 365 Developers (including contributing community members) create and maintain cloned repositories
366 of the upstream "master" branch.
363 These repositories are local to their development platforms and are used to develop changes. 367 These repositories are local to their development platforms and are used to develop changes.
364 When a developer is satisfied with a particular feature or change they “push” the changes 368 When a developer is satisfied with a particular feature or change they “push” the changes
365 up to the contrib repository. 369 up to the "contrib" repository.
366 Developers are responsible for keeping their local repository up-to-date with the master 370 Developers are responsible for keeping their local repository up-to-date with "master".
367 repository.
368 They are also responsible for straightening out any conflicts that might arise within files 371 They are also responsible for straightening out any conflicts that might arise within files
369 that are being worked on simultaneously by more than one person. 372 that are being worked on simultaneously by more than one person.
370 All this work is done locally on the developer’s machine before anything is pushed upstream 373 All this work is done locally on the developer’s machine before anything is pushed upstream
@@ -373,13 +376,13 @@
373 376
374 <para> 377 <para>
375 A somewhat formal method exists by which developers commit changes and push them into the 378 A somewhat formal method exists by which developers commit changes and push them into the
376 contrib area and subsequently request that the maintainer include them into the master repository. 379 "contrib" area and subsequently request that the maintainer include them into "master"
377 This process is called “submitting a patch” or “submitting a change.” 380 This process is called “submitting a patch” or “submitting a change.”
378 </para> 381 </para>
379 382
380 <para> 383 <para>
381 To summarize the environment: we have a single point of entry for changes into the project’s 384 To summarize the environment: we have a single point of entry for changes into the project’s
382 master repository, which is controlled by the project’s maintainer. 385 "master" branch of the Git repository, which is controlled by the project’s maintainer.
383 And, we have a set of developers who independently develop, test, and submit changes 386 And, we have a set of developers who independently develop, test, and submit changes
384 upstream for the maintainer to examine. 387 upstream for the maintainer to examine.
385 The maintainer then chooses which changes are going to become permanently a part of the project. 388 The maintainer then chooses which changes are going to become permanently a part of the project.
@@ -406,12 +409,13 @@
406 It is helpful to give them names associated with the particular feature or change 409 It is helpful to give them names associated with the particular feature or change
407 on which you are working. 410 on which you are working.
408 Once you are done with a feature or change you simply discard the branch.</para></listitem> 411 Once you are done with a feature or change you simply discard the branch.</para></listitem>
409 <listitem><para><emphasis>Merge Changes</emphasis> - The Git merge command allows you to take the 412 <listitem><para><emphasis>Merge Changes</emphasis> - The <filename>git merge</filename>
413 command allows you to take the
410 changes from one branch and fold them into another branch. 414 changes from one branch and fold them into another branch.
411 This process is especially helpful when more than a single developer might be working 415 This process is especially helpful when more than a single developer might be working
412 on different parts of the same feature. 416 on different parts of the same feature.
413 Merging changes also automatically identifies any collisions or “conflicts” 417 Merging changes also automatically identifies any collisions or “conflicts”
414 that might happen resulting from the same lines of code be altered by two different 418 that might happen resulting from the same lines of code being altered by two different
415 developers.</para></listitem> 419 developers.</para></listitem>
416 <listitem><para><emphasis>Manage Branches</emphasis> - Because branches are easy to use, you should 420 <listitem><para><emphasis>Manage Branches</emphasis> - Because branches are easy to use, you should
417 use a system where branches indicate varying levels of code readiness. 421 use a system where branches indicate varying levels of code readiness.
@@ -429,7 +433,7 @@
429 on which to develop.</para></listitem> 433 on which to develop.</para></listitem>
430 <listitem><para><emphasis>Patch Workflow</emphasis> - This workflow allows you to notify the 434 <listitem><para><emphasis>Patch Workflow</emphasis> - This workflow allows you to notify the
431 maintainer through an email that you have a change (or patch) you would like considered 435 maintainer through an email that you have a change (or patch) you would like considered
432 for the master repository. 436 for the "master" branch of the Git repository.
433 To send this type of change you format the patch and then send the email using the Git commands 437 To send this type of change you format the patch and then send the email using the Git commands
434 <filename>git format-patch</filename> and <filename>git send-email</filename>. 438 <filename>git format-patch</filename> and <filename>git send-email</filename>.
435 You can find information on how to submit later in this chapter.</para></listitem> 439 You can find information on how to submit later in this chapter.</para></listitem>
@@ -441,7 +445,7 @@
441 <title>Tracking Bugs</title> 445 <title>Tracking Bugs</title>
442 446
443 <para> 447 <para>
444 The Yocto Project uses Bugzilla to track bugs. 448 The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
445 This bug-tracking application works well for group development because it tracks bugs and code 449 This bug-tracking application works well for group development because it tracks bugs and code
446 changes, can be used to communicate changes and problems with developers, can be used to 450 changes, can be used to communicate changes and problems with developers, can be used to
447 submit and review patches, and can be used to manage quality assurance. 451 submit and review patches, and can be used to manage quality assurance.