Relax review criteria for the review cabal themselves, as discussed on-list
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Wed, 25 May 2011 15:02:43 +0000 (16:02 +0100)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Wed, 25 May 2011 15:02:43 +0000 (16:02 +0100)
Colin agreed in principle and nobody actually objected, so here we go...

HACKING

diff --git a/HACKING b/HACKING
index 036961f..bebf7ac 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -298,6 +298,20 @@ rules are:
  - if there's a live unresolved controversy about a change,
    don't commit it while the argument is still raging.
 
+ - at their discretion, members of the reviewer group may also commit
+   branches/patches under these conditions:
+
+   - the branch does not add or change API, ABI or wire-protocol
+
+   - the branch solves a known problem and is covered by the regression tests
+
+   - there are no objections from the rest of the review group within
+     a week of the patches being attached to Bugzilla
+
+   - the committer gets a positive review on Bugzilla from someone they
+     consider qualified to review the change (e.g. a colleague with D-Bus
+     experience; not necessarily a member of the reviewer group)
+
  - regardless of reviews, to commit a patch:
     - make check must pass
     - the test suite must be extended to cover the new code