[libvirt] [PATCH] docs: Improve patch submission guidelines
We should really advise (new) developers to send rebased patches
that apply cleanly and use git-send-email rather than all other
obscure ways.
---
docs/hacking.html.in | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 89f9980..96859fd 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -11,19 +11,43 @@
<li><p>Post patches in unified diff format. A command similar to this
should work:</p>
-<pre>
+<del><pre>
diff -urp libvirt.orig/ libvirt.modified/ > libvirt-myfeature.patch
-</pre>
+</pre></del>
<p>
or:
</p>
<pre>
git diff > libvirt-myfeature.patch
</pre>
+ However, the usual workflow of libvirt developer is:
+<pre>
+ git checkout master
+ git pull
+ git checkout -b workbranch
+ Hack, committing any changes along the way
+</pre>
+ Then, when you want to post your patches:
+<pre>
+ git checkout master
+ git pull
+ git checkout workbranch
+ git rebase master
+ (fix any conflicts)
+ git send-email --compose --to=libvir-list(a)redhat.com master
+</pre>
+ Please follow this as close as you can, especially the rebase and git
+ send-email part as it makes developer's, who is reviewing your patch
+ set, life easier. One should avoid sending patches as attachment but
+ rather send them in email body among with commit message.
</li>
+
<li>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.</li>
+ the sequence of patches fits together. Moreover, please keep in mind that
+ it's required to be able to compile cleanly after each patch.
+ </li>
+
<li>Make sure your patches apply against libvirt GIT. Developers
only follow GIT and don't care much about released versions.</li>
<li><p>Run the automated tests on your code before submitting any
changes.
--
1.7.8.6