[libvirt] Suggestion on commit rules when fixing breakages

[Daniel Veillard]

On Thu, Oct 16, 2008 at 10:41:02PM +0900, Atsushi SAKAI wrote:
> Hi, Daniel
> 
>  This proposal seems approved.
> Does this proposal message goes to somewhere in libvirt document?

  Jim pointed out I completely misunderstood your comment :-)
Yes you're right, it should be generally documented. I suggest
adding the following new section at the end of the HACKING file to
document the commiting policies:

--------------------------------

                Libvirt commiters guidelines
                ============================

The AUTHORS files indicates the list of people with commit acces right
who can actually merge the patches.

The general rule for commiting patches is to make sure it has been reviewed
properly in the mailing-list first, usually if a couple of persons gave an
ACK or +1 to a patch and nobody raised an objection on the list it should
be good to go. If the patch touches a part of the code where you're not the
main maintainer or not have a very clear idea of how things work, it's better
to wait for a more authoritative feedback though. Before commiting please
also rebuild locally and run 'make check syntax-check' and make sure they
don't raise error. Try to look for warnings too for example configure with
   --enable-compile-warnings=error
which adds -Werror to compile flags, so no warnings get missed

Exceptions to that 'review and approval on the list first' is fixing failures
to build:
  - if a recently commited patch breaks compilation on a platform
    or for a given driver then it's fine to commit a minimal fix
    directly without getting the review feedback first
  - similary if make check or make syntax-chek breaks, if there is
    an obvious fix, it's fine to commit immediately
The patch should still be sent to the list (or tell what the fix was if
trivial) and 'make check syntax-check' should pass too before commiting
anything
Similary typo fixes for documentation and code comments can be managed
in the same way, but still make sure they get reviewed if non-trivial.

--------------------------------

  I think it documents the current practice, feedback welcome :-)

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/