<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On 30 June 2014 21:04, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">As a maintainer of a small CI system that tends to get backed up during milestone rush hours, it would be nice if we were allowed up to 12 hours. However, as a developer this seems like too long to have to wait for the results of a patch.<br>
</p></blockquote><div>Interesting question!</div><div><br></div><div>Taking one hundred steps back :-) what is the main purpose of the 3rd party reviews, and what are the practical consequences when they are not promptly available?</div>
<div><br></div><div>Is the main purpose to allow 3rd parties to automatically object to changes that will cause them problems, and the practical consequence of a slow review being that OpenStack may merge code that will cause a problem for that third party?</div>
<div><br></div><div>How do genuine negative reviews by 3rd party CIs play out in practice? (Do the change author and the 3rd party get together offline to work out the problem? Or does the change-author treat Gerrit as an edit-compile-run loop to fix the problem themselves?) I'd love to see links to such reviews, if anybody has some? (I've only seen positive reviews and false-negative reviews from 3rd party CIs so far in my limited experience.)</div>
<div><br></div><div>Generally it seems like 12 hours is the blink of an eye in terms of the whole lifecycle of a change, or alternatively an eternity in terms of somebody sitting around waiting to take action on the result.</div>
<div><br></div><div><br></div></div></div></div>