[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