diff --git a/docs/committer-guidelines.rst b/docs/committer-guidelines.rst new file mode 100644 index 0000000000..3be08e6fed --- /dev/null +++ b/docs/committer-guidelines.rst @@ -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 diff --git a/docs/hacking.rst b/docs/hacking.rst index 35c246bf26..39e303c103 100644 --- a/docs/hacking.rst +++ b/docs/hacking.rst @@ -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 `__. - -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