<div dir="ltr"><div>Not entirely sure what you're arguing here.  "It's not a corner case when you're in the corner"?</div><div><br></div>It's hard to reason without data either way, but I don't think "add an extra flag to your trychooser syntax" is a high bar for folks in that situation.  By default, I believe that the behaviour of our tooling should be conservative in terms of resource usage that negatively impacts everyone, and we should make it easy for those who need to consume more to explicitly ask for that.  It's still much less work and _vastly_ less effective than mandating a reliance on manually killing jobs.<div><br></div><div>-- Mike</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 15, 2016 at 3:56 PM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15/04/2016 20:46, Mike Connor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For cases where a developer needs to run multiple runs at once, we can add<br>
an override in the trychooser syntax.  I think that's a corner case<br>
</blockquote>
<br></span>
It isn't when you do any kind of talos "need to fix / not regress perf" work.<br>
<br>
I agree with Jim that we should either force the user to choose or "only" warn when duplicate-bug trypushes happen.<span class="HOEnZb"><font color="#888888"><br>
<br>
~ Gijs<br>
<br>
</font></span></blockquote></div><br></div>