On Wed, Aug 15, 2012 at 11:02 AM, Barak Raveh barak.raveh@gmail.com wrote:
> guys, let's try to get one day of TOTALLY clean tests :) can people in > charge of* cgal, isd and multifit *(Fast build only)** 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'll handle that too).
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.
> If there's a complicated issue behind these failures, we can temporarily > disable those tests until the relevant person get to work on it. > 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't we have a test failing to tell us that?
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.