<br><p dir="ltr"></p>
<p dir="ltr">On Saturday, December 28, 2013 6:05:38 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:</p>
<blockquote><p dir="ltr">My inbox has been filled with <a href="mailto:llvm.buildmaster@lab.llvm.org">llvm.buildmaster</a><a href="mailto:llvm.buildmaster@lab.llvm.org">@</a><a href="mailto:llvm.buildmaster@lab.llvm.org">lab.llvm.org</a> build<br>

failure notifications lately.</p>
<p dir="ltr">The two problems appear to be:</p>
<p dir="ltr">  1) Getting notifications for breakage that was introduced by an<br>
unrelated commit, often in a module I don't work on. Usually the<br>
original committer is working on or has already landed the necessary fix.</p>
<p dir="ltr">  2) A cascade of dozens of notifications from various build servers<br>
that continue to flood in over the course of 24 hours after the issue<br>
was fixed.</p>
<p dir="ltr">These two conflate and produce a high signal-to-noise ratio, and in<br>
practice you have to filter them out which means you no longer get a<br>
ping on your phone when you need it.</p>
<p dir="ltr">Presumably a full fix is a non-trivial CI engineering problem, but are<br>
there simple measures get the situation back under control?</p>
<p dir="ltr">Doesn't have to be perfect as long as it reduces the dozens of mails<br>
every day to something more manageable. Ideas:</p>
<p dir="ltr">  1) Only send direct mail when the recipient is the single name in the<br>
blame list.</p>
<p dir="ltr">  2) Set an In-Reply-To header in order to thread all failure<br>
notifications related to a specific SVN revision. Most email clients<br>
will let you silence the thread once you've confirmed the issue has been<br>
resolved.</p>
<p dir="ltr">3) Or even simpler, don't send failure mail from any builders outside<br>
the "fast" set? Otherwise the important failures blocking everyone's<br>
work get drowned out in the noise.</p>
<p dir="ltr">Sorry to send a feature request without patches but I'm not familiar<br>
with the CI infrastructure and this looks like a fairly recent<br>
development (or is it just me?</p>
</blockquote>
<br><br>This isn't new. Just how the boys have always worked.<br><br>The biggest thing would be to move boots over to the phased builder infrastructure pioneered by apple (they use it internally and I believe most of it has been upstreamed by Daniel Dunbar and David Tweed) that sets up  dependencies (eg: testing debug info depends on the compiler paying the basic check first) and refuse/caching of build product (eg: use the output of the basic checks to test the debug info, rather than rebuilding the compiler on every builder).<br>
<br>This would reduce noise and increase build slave efficiency and granularity to produce smaller blame lists.<br><blockquote><p dir="ltr"><br>
Alp.<br></p>
<p dir="ltr">--<br>
<a href="http://www.nuanti.com">http://www.nuanti.com</a><br>
the browser experts</p>
<p dir="ltr">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu">http://</a><a href="http://llvm.cs.uiuc.edu">llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://</a><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">lists.cs.uiuc.edu</a><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">/mailman/</a><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">listinfo</a><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">/</a><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a><br>

</p>
</blockquote>
<p dir="ltr"><br>
</p>