summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual
diff options
context:
space:
mode:
authorRobert P. J. Day <rpjday@crashcourse.ca>2011-11-02 13:33:07 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-11-08 16:26:30 +0000
commitbf1e5c641351a71aef256e8782855fa33e091503 (patch)
treead1d6ad1d84a37ff8fe20e4cd683d81e7b6282f6 /documentation/dev-manual
parent296fd7a7def388feb70f18128e747993eb6ab9a9 (diff)
downloadpoky-bf1e5c641351a71aef256e8782855fa33e091503.tar.gz
documentation/dev-manual/dev-manual-newbie.xml: Robert P. J. Edits
Robert suggested some minor wording changes that are good. (From yocto-docs rev: 50822bc3722e2f3b0a73ed837842ddc5c7595c7b) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r--documentation/dev-manual/dev-manual-newbie.xml21
1 files changed, 12 insertions, 9 deletions
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 3eef7460f9..3a57942481 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -369,7 +369,7 @@
369 will allow the change, and for ultimately pushing the change from your local Git repository 369 will allow the change, and for ultimately pushing the change from your local Git repository
370 into the project’s upstream (or master) repository.</para></listitem> 370 into the project’s upstream (or master) repository.</para></listitem>
371 <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that 371 <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
372 possibly need added and committed.</para></listitem> 372 possibly need to be added and committed.</para></listitem>
373 <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes 373 <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
374 your working branch. 374 your working branch.
375 This command is analogous to “cd”.</para></listitem> 375 This command is analogous to “cd”.</para></listitem>
@@ -423,7 +423,7 @@
423 In particular, the information covers basic practices that describe roles and actions in a 423 In particular, the information covers basic practices that describe roles and actions in a
424 collaborative development environment. 424 collaborative development environment.
425 Again, if you are familiar with this type of development environment, you might want to just 425 Again, if you are familiar with this type of development environment, you might want to just
426 skip the section. 426 skip this section.
427 </para> 427 </para>
428 428
429 <para> 429 <para>
@@ -436,7 +436,7 @@
436 The maintainer is responsible for allowing changes in from other developers and for 436 The maintainer is responsible for allowing changes in from other developers and for
437 organizing the underlying branch structure to reflect release strategies and so forth. 437 organizing the underlying branch structure to reflect release strategies and so forth.
438 <note>You can see who is the maintainer for Yocto Project files by examining the 438 <note>You can see who is the maintainer for Yocto Project files by examining the
439 <filename>distro_tracking_fields</filename> file in the Yocto Project 439 <filename>distro_tracking_fields.inc</filename> file in the Yocto Project
440 <filename>meta/conf/distro/include</filename> directory.</note> 440 <filename>meta/conf/distro/include</filename> directory.</note>
441 </para> 441 </para>
442 442
@@ -475,7 +475,7 @@
475 "master" branch of the Git repository, which is controlled by the project’s maintainer. 475 "master" branch of the Git repository, which is controlled by the project’s maintainer.
476 And, we have a set of developers who independently develop, test, and submit changes 476 And, we have a set of developers who independently develop, test, and submit changes
477 to "contrib" areas for the maintainer to examine. 477 to "contrib" areas for the maintainer to examine.
478 The maintainer then chooses which changes are going to become permanently a part of the project. 478 The maintainer then chooses which changes are going to become a permanent part of the project.
479 </para> 479 </para>
480 480
481 <para> 481 <para>
@@ -489,12 +489,15 @@
489 For more detailed information about these strategies see 489 For more detailed information about these strategies see
490 <ulink url='http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html'>Git Workflows</ulink>. 490 <ulink url='http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html'>Git Workflows</ulink>.
491 <itemizedlist> 491 <itemizedlist>
492 <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep your changes you commit 492 <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep the changes you commit
493 small as compared to bundling many disparate changes into a single commit. 493 small as compared to bundling many disparate changes into a single commit.
494 This practice not only keeps things manageable but also allows the maintainer 494 This practice not only keeps things manageable but also allows the maintainer
495 to more easily include or refuse changes.</para> 495 to more easily include or refuse changes.</para>
496 <para>It is also good practice to leave the repository in a state that allows you to 496 <para>It is also good practice to leave the repository in a state that allows you to
497 still successfully build your project.</para></listitem> 497 still successfully build your project. In other words, do not commit half of a feature,
498 then add the other half in a separate, later commit.
499 Each commit should take you from one buildable project state to another
500 buildable state.</para></listitem>
498 <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and 501 <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and
499 delete local branches in your working Git repository. 502 delete local branches in your working Git repository.
500 You can name these branches anything you like. 503 You can name these branches anything you like.
@@ -527,7 +530,7 @@
527 <filename>send-pull-request</filename> that ship with the release to facilitate this 530 <filename>send-pull-request</filename> that ship with the release to facilitate this
528 workflow. 531 workflow.
529 You can find these scripts in the local Yocto Project files Git repository in 532 You can find these scripts in the local Yocto Project files Git repository in
530 <filename>scripts</filename>.</para></listitem> 533 the <filename>scripts</filename> directory.</para></listitem>
531 <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the 534 <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
532 maintainer through an email that you have a change (or patch) you would like considered 535 maintainer through an email that you have a change (or patch) you would like considered
533 for the "master" branch of the Git repository. 536 for the "master" branch of the Git repository.
@@ -615,7 +618,7 @@
615 </para> 618 </para>
616 619
617 <para> 620 <para>
618 When you send a patch, be sure to include a "signed-off-by:" 621 When you send a patch, be sure to include a "Signed-off-by:"
619 line in the same style as required by the Linux kernel. 622 line in the same style as required by the Linux kernel.
620 Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1 623 Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
621 as follows: 624 as follows:
@@ -661,7 +664,7 @@
661 </para> 664 </para>
662 665
663 <para> 666 <para>
664 When you form a commit, you must follow certain standards established by the 667 When you create a commit, you must follow certain standards established by the
665 Yocto Project development team. 668 Yocto Project development team.
666 For each commit, you must provide a single-line summary of the change and you 669 For each commit, you must provide a single-line summary of the change and you
667 almost always provide a more detailed description of what you did (i.e. the body 670 almost always provide a more detailed description of what you did (i.e. the body