External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-31 10:05:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Add committer-guidelines.rst

Browse Source 
While it's good to have these rules written down for reference, they
apply exclusively to committers, who by definition are familiar with
the project and probably work on it daily, so there's no need to have
them front and center when a separate page will do.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This commit is contained in:
Andrea Bolognani 2020-04-06 15:00:48 +02:00
parent 820068c9f4
commit 319004da2e
2 changed files with 33 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
docs/committer-guidelines.rst Normal file
View File

@ -0,0 +1,33 @@
====================
Committer guidelines
====================
The AUTHORS files indicates the list of people with commit access
right who can actually merge the patches.
The general rule for committing a patch is to make sure it has
been reviewed properly in the mailing-list first, usually if a
couple of people 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 where you do not have a very clear idea of how things work,
it's better to wait for a more authoritative feedback though.
Before committing, please also rebuild locally, run 'make check
syntax-check', and make sure you don't raise errors.
An exception to 'review and approval on the list first' is fixing
failures to build:
- if a recently committed 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
- if make check or make syntax-check 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
committing anything
- fixes for documentation and code comments can be managed in the
same way, but still make sure they get reviewed if non-trivial.
- (ir)regular pulls from other repositories or automated updates,
such as the keycodemap submodule updates, pulling in new
translations or updating the container images for the CI system

33
docs/hacking.rst
View File

@ -321,36 +321,3 @@ There is more on this subject, including lots of links to
background reading on the subject, on `Richard Jones' guide to
working with open source
projects <http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/>`__.
Libvirt committer guidelines
============================
The AUTHORS files indicates the list of people with commit access
right who can actually merge the patches.
The general rule for committing a patch is to make sure it has
been reviewed properly in the mailing-list first, usually if a
couple of people 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 where you do not have a very clear idea of how things work,
it's better to wait for a more authoritative feedback though.
Before committing, please also rebuild locally, run 'make check
syntax-check', and make sure you don't raise errors.
An exception to 'review and approval on the list first' is fixing
failures to build:
- if a recently committed 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
- if make check or make syntax-check 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
committing anything
- fixes for documentation and code comments can be managed in the
same way, but still make sure they get reviewed if non-trivial.
- (ir)regular pulls from other repositories or automated updates,
such as the keycodemap submodule updates, pulling in new
translations or updating the container images for the CI system