On Wed, Aug 15, 2012 at 11:02 AM, Barak Raveh <span dir="ltr">&lt;<a href="mailto:barak.raveh@gmail.com" target="_blank">barak.raveh@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
guys, let&#39;s try to get one day of TOTALLY clean tests :) can people in charge of<b> cgal, isd and multifit </b>(Fast build only)<b></b> give a quick look to see if they can quickly solve the test issues (the atom case is known, and if other tests are solved, we&#39;ll handle that too). </blockquote>
<div>The cgal one is something that does not work with the version of cgal installed there. A test failure on that platform seems like the most correct situation.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If there&#39;s a complicated issue behind these failures, we can temporarily disable those tests until the relevant person get to work on it. <br></blockquote><div>Why would that be an improvement (in the case where something in the module is broken as opposed to the test being a bad test)? If something is broken, shouldn&#39;t we have a test failing to tell us that?<br>
<br>That said, I would really like more fine grained display (eg number of failing tests). That way one could tell at a glance when new tests broke.<br></div></div>