[PATCH] drm-misc: Document review best practices

Daniel Vetter daniel.vetter at ffwll.ch
Tue Feb 28 09:46:40 UTC 2017


Let's make sure that review doesn't go through needless cycles. Diff
doesn't show this, but this is only for the "small drivers" part of
drm.

Acked-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Acked-by: Jani Nikula <jani.nikula at linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
---
 drm-misc.rst | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drm-misc.rst b/drm-misc.rst
index 73882dc55be6..d6367686d561 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -72,7 +72,7 @@ Merge Criteria
 
 Right now the only hard merge criteria are:
 
-* Patch is properly reviewed or at least ack, i.e. don't just push your own
+* Patch is properly reviewed or at least Ack, i.e. don't just push your own
   stuff directly.
 
 * drm-misc is for drm core (non-driver) patches, subsystem-wide refactorings,
@@ -132,6 +132,16 @@ Slightly different rules apply:
   most cases this will just along the lines of "Looks good, Ack".  drm-misc
   maintainers will help out with getting that review market going.
 
+* Best practice for review: When you have some suggestions and comments for
+  future work, please make sure you don't forget your Ack tag to unblock the
+  original patch. And if you think something really must be fixed before
+  merging, please give a conditional Ack along the lines of "Fix
+  $specific_thing, with that addressed, Ack". The goal is to always have a clear
+  and reasonable speedy path towards getting the patch merged. For authors on
+  the other side, just do the minimal rework and push the patch, and do any
+  more involved rework in follow-up work. This way lenghty review cycles get
+  avoided, which are a drag for both reviewer and author.
+
 Tooling
 =======
 
-- 
2.11.0



More information about the dri-devel mailing list