<div dir="ltr">On 3 July 2014 02:44, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">The main purpose is to let change reviewers know that a change might<br></div>
be problematic for a piece of code not well tested by the gate</blockquote><div><br></div><div>Just a thought:</div><div><br></div><div>A "sampling" approach could be a reasonable way to stay responsive under heavy load and still give a strong signal to reviewers about whether a change is likely to be problematic.</div>
<div><br></div><div>I mean: Kevin mentions that his CI gets an hours-long queue during peak review season. One way to deal with that could be skipping some events e.g. toss a coin to decide whether to test the next revision of a change that he has already +1'd previously. That would keep responsiveness under control even when throughput is a problem.</div>
<div><br></div><div>(A bit like how a router manages a congested input queue or how a sampling profiler keeps overhead low.)</div><div><br></div><div>Could be worth keeping the rules flexible enough to permit this kind of thing, at least?</div>
<div><br></div><div><br></div></div></div></div>