I argue that it's better to exonerate all CLs at once so that developers don't keep manually reset flags, not realizing the system will do it later on.

It's much better to instead improve the PreCQ and CQ CL selection logic to limit the number of CL "sets" it will test at a time.

That approach should be easier for users to understand, and be more flexible, since it will also help with recovery build "build down" issues, and from unusually busy development days. We SHOULD generate omens any time there is a backlog of CLs to test, however.

We might need to put some thought into the "fairest" way for both the CQ and PreCQ to decide which CLs to test first if they are hitting their limits.

OK, so let's not rate-limit exonerator. Bug title changed.

I'd argue that a fair way to rate-limit CLs in the CQ would be to use CL-Scanner to select non-riksy subsets of the CLs. The whole reason we want to select a subset of CLs to begin with is to reduce the risk of the run failing, so it would make sense to take advantage of the CL risk signal to make that decision more intelligently.

Passing to jclinton@ to prioritize

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

As it says above, no it hasn't been.

Will be triaged during our triage process if it has no owner.