diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 803807df21..6dfec666be 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -710,17 +710,33 @@ Push Your Commits to a "Contrib" Upstream: - Push the change to the upstream "contrib" repository by - using the git push command. + If you have arranged for permissions to push to an + upstream contrib repository, push the change to that + repository: + + $ git push upstream_remote_repo local_branch_name + + For example, suppose you have permissions to push into the + upstream meta-intel-contrib + repository and you are working in a local branch named + your_name/README. + The following command pushes your local commits to the + meta-intel-contrib upstream + repository and puts the commit in a branch named + your_name/README: + + $ git push meta-intel-contrib your_name/README + Determine Who to Notify: - Determine the maintainer that you need to notify for - the change. + Determine the maintainer or the mailing list + that you need to notify for the change. Before submitting any change, you need to be sure - who the maintainer is that you need to notify. - Use either of these methods to find out: + who the maintainer is or what mailing list that you need + to notify. + Use either these methods to find out: Maintenance File: @@ -747,16 +763,19 @@ From the list, you can see who is responsible for the bulk of the changes against the file. + + Examine the List of Mailing Lists: + For a list of the Yocto Project and related mailing + lists, see the + "Mailing lists" + section in the Yocto Project Reference Manual. + - For a list of the Yocto Project and related mailing lists, - see the - "Mailing lists" - section in the Yocto Project Reference Manual. Make a Pull Request: - Notify the maintainer that you have pushed a change by - making a pull request. + Notify the maintainer or the mailing list that you have + pushed a change by making a pull request. The Yocto Project provides two scripts that conveniently let you generate and send pull requests to the @@ -765,22 +784,53 @@ and send-pull-request. You can find these scripts in the scripts directory within the - Source Directory. + Source Directory + (e.g. ~/poky/scripts). Using these scripts correctly formats the requests without introducing any whitespace or HTML formatting. - The maintainer that receives your patches needs to be - able to save and apply them directly from your emails. + The maintainer that receives your patches either directly + or through the mailing list needs to be able to save and + apply them directly from your emails. Using these scripts is the preferred method for sending patches. - For help on using these scripts, simply provide the - -h argument as follows: + First, create the pull request. + For example, the following command runs the script, + specifies the upstream repository in the contrib directory + into which you pushed the change, and provides a subject + line in the created patch files: + $ ~/poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README" + + Running this script forms + *.patch files in a folder named + pull-PID + in the current directory. + One of the patch files is a cover letter. + + Before running the + send-pull-request script, you must + edit the cover letter patch to insert information about + your change. + After editing the cover letter, send the pull request. + For example, the following command runs the script and + specifies the patch directory and email address. + In this example, the email address is a mailing list: + + $ ~/poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@yoctoproject.org + + You need to follow the prompts as the script is + interactive. + + For help on using these scripts, simply provide the + -h argument as follows: + $ poky/scripts/create-pull-request -h $ poky/scripts/send-pull-request -h - + + @@ -918,9 +968,10 @@ maintainer would. The git send-email command is - the preferred method for sending your patches since there - is no risk of compromising whitespace in the body of the - message, which can occur when you use your own mail client. + the preferred method for sending your patches using + email since there is no risk of compromising whitespace + in the body of the message, which can occur when you use + your own mail client. The command also has several options that let you specify recipients and perform further editing of the email message.