<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 9:38 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.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 08/26/2015 09:27 AM, Renato Golin via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 26 August 2015 at 17:21, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(oh, and add long cycle times to the list of issues - people do have a<br>
tendency to ignore bots that come back with giant blame lists & no obvious<br>
determination as to who's patch caused the problem, if any)<br>
</blockquote>
Yes, but remember, not all hardware is as fast as a multi-core Xeon<br>
server. Build times can't always be controlled.<br>
</blockquote></span>
No, but there are many known partial solutions.  We can explore some of them if build time is the only issue.<br>
<br>
Some options (I don't know which if any have already been explored)<br>
- Kick off builds on slow bots at revisions which have passed a fast bot<br></blockquote><div><br>This ^<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Overlap builds on different pieces of hardware so that revision ranges are smaller (i.e. "that change was in the previous build and didn't fail, so it can't be that")<br>
- Build incrementally with occasional clean builds at already known good revisions (or for failure recovery)<br></blockquote><div><br>this ^<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Separate build and test.  Cross build on a faster machine then transfer the binaries to a slower test machine.  Run only a build on the slow machine.  (i.e. decrease latency of build+test to latency of build OR test)<br></blockquote><div><br>and this ^ would all be nice, but require a bigger investment by someone in terms of major buildbot overhaul/improvements - Apple had an internal system (their "phase based builder") that they upstreamed some of, but then switched to Jenkins. Not sure if their Jenkins config (public or private) does this, but might do.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Consider using an emulator on a faster machine to get initial results.  Only kick off builds on hardware for changes that pass the emulator.  (This is a particular variant of (1) above.)<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
But I agree with you on all accounts. The bot owner should bear the<br>
responsibility of his/her own unstable bots. If it brings less value<br>
than it adds cost to the community, it should be moved to a separate<br>
buildmaster that doesn't email people around, but can be accessed, so<br>
the owner can point breakages to devs.<br>
<br>
cheers,<br>
--renato<br></span><span class="">
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</span></blockquote>
<br>
</blockquote></div><br></div></div>