On 3 July 2014 02:44, Michael Still <[email protected]> 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?
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
