mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-14 21:49:33 +02:00
Code Issues Packages Projects Releases Wiki Activity

documentation/dev-manual: Edits from Tom Zanussi.

Browse Source 
Tom Zanussi provided a review up through part of the "model"
chapter.  I have implemented his comments mosty verbatim.

Reported-by: Tom Zanussi
(From yocto-docs rev: 693d4fadd4b34ffef9953fb1850d381ff7c028a3)

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-11-10 13:28:32 -08:00
committed by Richard Purdie
parent 684c35b7aa
commit 39899b2212
4 changed files with 28 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -11,7 +11,7 @@
closed, proprietary environment.
Additionally, the Yocto Project uses specific tools and constructs as part of its development
environment.
The chapter specifically addresses open source philosophy, licensing issues, code repositories,
This chapter specifically addresses open source philosophy, licensing issues, code repositories,
the open source distributed version control system Git, and best practices using the Yocto Project.
</para>
@@ -73,7 +73,7 @@
Conversely, if you are a developer that is not interested in contributing back to the
Yocto Project, you have the ability to simply download and extract release tarballs
and use them within the Yocto Project environment.
All that is required is a particular release of Yocto Project, a kernel, and
All that is required is a particular release of the Yocto Project and
your application source code.
</para>
@@ -599,7 +599,7 @@
</para>
<para>
Following is some guidance on which mailing list to use for what type of defect:
The following is some guidance on which mailing list to use for what type of defect:
<itemizedlist>
<listitem><para>For defects against the Yocto Project build system Poky, send
your patch to the
@@ -778,6 +778,11 @@
<para>If you provide several commits as part of the command,
the <filename>git format-patch</filename> command produces a numbered
series of files in the current directory – one for each commit.
If you have more than one patch, you should also use the
<filename>--cover</filename> option with the command, which generates a
cover letter as the first "patch" in the series.
You can then edit the cover letter to provide a description for
the series of patches.
For information on the <filename>git format-patch</filename> command,
see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the
<filename>man git-format-patch</filename> command.</para></listitem>
@@ -790,7 +795,15 @@
or remote Mail Transport Agent (MTA) such as
<filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
<filename>smtp</filename> configuration in your Git <filename>config</filename>
file.</para>
file.
If you are submitting patches through email only, it is very important
that you submit them without any whitespace or HTML formatting that
either you or your mailer introduces.
The maintainer that receives your patches needs to be able to save and
apply them directly from your emails.
A good way to verify that what you are sending will be applicable by the
maintainer is to do a dry run and send them to yourself and then
save and apply them as the maintainer would.</para>
<para>The <filename>git send-email</filename> 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.