Open Stack

On 3 July 2014 02:44, Michael Still <mikal at stillhq.com> wrote:

> The main purpose is to let change reviewers know that a change might
> be problematic for a piece of code not well tested by the gate


Just a thought:

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.

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.

(A bit like how a router manages a congested input queue or how a sampling
profiler keeps overhead low.)

Could be worth keeping the rules flexible enough to permit this kind of
thing, at least?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/5edcf46f/attachment.html>