External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-03-07 17:28:15 +00:00
Code

docs: point out git send-email location, be more stern about make check

Browse Source 
An email came to libvir-list wondering why the git send-email command
was missing in spite of having git installed; this is due to the
send-email command being in a sub-package of the main git package.

While touching the hacking file, I thought it would be useful to 1)
indicate the location of the source (docs/hacking.html.in) in the
message at the top of HACKING, and also to make the note about running
"make check" and "make syntax-check" a bit more stern.
This commit is contained in:
Laine Stump 2012-09-06 13:21:21 -04:00
parent 892242519a
commit 7038322991
3 changed files with 34 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
HACKING
View File

@ -1,5 +1,6 @@
-*- buffer-read-only: t -*- vi: set ro:
DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY!
DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY
from docs/hacking.html.in!
@ -32,11 +33,14 @@ Then, when you want to post your patches:
git pull --rebase
(fix any conflicts)
git send-email --cover-letter --no-chain-reply-to --annotate --to=libvir-list@redhat.com master
git send-email --cover-letter --no-chain-reply-to --annotate \
--to=libvir-list@redhat.com master
For a single patch you can omit "--cover-letter", but series of a two or more
patches needs a cover letter. If you get tired of typing
"--to=libvir-list@redhat.com" designation you can set it in git config:
(Note that the "git send-email" subcommand is usually not in the main git
package, but part of a sub-package called "git-email".) For a single patch you
can omit "--cover-letter", but series of a two or more patches needs a cover
letter. If you get tired of typing "--to=libvir-list@redhat.com" designation
you can set it in git config:
git config sendemail.to libvir-list@redhat.com
@ -56,9 +60,11 @@ though).
(3) Split large changes into a series of smaller patches, self-contained if
possible, with an explanation of each patch and an explanation of how the
sequence of patches fits together. Moreover, please keep in mind that it's
required to be able to compile cleanly after each patch. A feature does not
have to work until the end of a series, as long as intermediate patches don't
cause test-suite failures.
required to be able to compile cleanly (*including* "make check" and "make
syntax-check") after each patch. A feature does not have to work until the end
of a series, but intermediate patches must compile and not cause test-suite
failures (this is to preserve the usefulness of "git bisect", among other
things).

28
docs/hacking.html.in
View File

@ -31,11 +31,16 @@
<pre>
git pull --rebase
(fix any conflicts)
git send-email --cover-letter --no-chain-reply-to --annotate --to=libvir-list@redhat.com master
git send-email --cover-letter --no-chain-reply-to --annotate \
--to=libvir-list@redhat.com master
</pre>
<p>For a single patch you can omit <code>--cover-letter</code>, but
series of a two or more patches needs a cover letter. If you get tired
of typing <code>--to=libvir-list@redhat.com</code> designation you can
<p>(Note that the "git send-email" subcommand may not be in
the main git package and using it may require installion of a
separate package, for example the "git-email" package in
Fedora.) For a single patch you can omit
<code>--cover-letter</code>, but a series of two or more
patches needs a cover letter. If you get tired of typing
<code>--to=libvir-list@redhat.com</code> designation you can
set it in git config:</p>
<pre>
git config sendemail.to libvir-list@redhat.com
@ -55,12 +60,15 @@
</li>
<li><p>Split large changes into a series of smaller patches,
self-contained if possible, with an explanation of each patch and an
explanation of how the sequence of patches fits together. Moreover,
please keep in mind that it's required to be able to compile cleanly
after each patch. A feature does not have to work until the end of a
series, as long as intermediate patches don't cause test-suite
failures.</p>
self-contained if possible, with an explanation of each patch
and an explanation of how the sequence of patches fits
together. Moreover, please keep in mind that it's required to
be able to compile cleanly (<b>including</b> <code>make
check</code> and <code>make syntax-check</code>) after each
patch. A feature does not have to work until the end of a
series, but intermediate patches must compile and not cause
test-suite failures (this is to preserve the usefulness
of <code>git bisect</code>, among other things).</p>
</li>
<li>Make sure your patches apply against libvirt GIT. Developers

3
docs/hacking2.xsl
View File

@ -18,7 +18,8 @@
<xsl:template match="/">
<xsl:text>-*- buffer-read-only: t -*- vi: set ro:
DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY!
DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY
from docs/hacking.html.in!