HACKING: add explanation why we want cool-off times as long as a week or two

Change-Id: I281e9145f43bc7ac173e02c4e209834f0deaae2b
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Reviewed-on: http://openocd.zylin.com/254
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-by: Mathias Küster <kesmtp@freenet.de>
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>

diff --git a/HACKING b/HACKING
index 6d89b01e357b4970b317461ee41c0bec37a98600..ed971715406b79db363d395920915294ed7dfcc8 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -121,4 +121,25 @@ git push review
 
 Further reading:
 
-http://www.coreboot.org/Git
\ No newline at end of file
+http://www.coreboot.org/Git
+
+
+When can I expect my contribution to be committed?
+==================================================
+
+The code review is intended to take as long as a week or two to allow
+maintainers and contributors who work on OpenOCD only in their spare
+time oportunity to perform a review and raise objections.
+
+With Gerrit much of the urgency of getting things committed has been
+removed as the work in progress is safely stored in Gerrit and
+available if someone needs to build on your work before it is
+submitted to the official repository.
+
+Another factor that contributes to the desire for longer cool-off
+times (the time a patch lies around without any further changes or
+comments), it means that the chances of quality regression on the
+master branch will be much reduced.
+
+If a contributor pushes a patch, it is considered good form if another
+contributor actually approves and submits that patch.