[libvirt] [PATCH] docs: Improve patch submission guidelines

[Michal Privoznik]

On 09.07.2012 10:15, Michal Privoznik wrote:
> 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 at 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>
> +

huh, these <li/> I am touching should have really been
<li><p>...</p></li>. Fixed on my local branch.

Btw: what about this HACKING file? I mean it's autogenerated and watched
by git as well. Or do want new developers to read this file on bare
checkout before first build? I should have commited changes to this file
then too, shouldn't I?