<div dir="auto">Hi Noel,<div dir="auto"><br></div><div dir="auto">The reason to choose it is that it is most likely to fail among all the builds. If it fails, then there is no need to run others. If we choose a job that is stable and likely to pass every patch, then all other builds also need to be run, saving no computation.</div><div dir="auto"><br></div><div dir="auto">I'm open to all advice on the build design.</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto">Baole Fang </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 18, 2023, 4:26 AM Noel Grandin <<a href="mailto:noelgrandin@gmail.com">noelgrandin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hi</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Why are we fronting the ml jenkins job with the least reliable subjob?<br><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Surely we should be using the gcc job - which is faster and more reliable.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Regards, Noel Grandin</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div>
</blockquote></div>