summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorSimon McVittie <simon.mcvittie@collabora.co.uk>2011-05-25 16:02:43 +0100
committerSimon McVittie <simon.mcvittie@collabora.co.uk>2011-05-25 16:02:43 +0100
commit4bcffe1e05cfc22eb29b41d39f7ceca14b45a9a8 (patch)
tree95df035ab33b054fcb2a84843d2c551070c6b071 /HACKING
parentec48c71f7098cc53200e5d7c099ab00e4f569087 (diff)
Relax review criteria for the review cabal themselves, as discussed on-list
Colin agreed in principle and nobody actually objected, so here we go...
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING14
1 files changed, 14 insertions, 0 deletions
diff --git a/HACKING b/HACKING
index 036961f2..bebf7ac1 100644
--- 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