<div class="gmail_quote">On Mon, Jul 23, 2012 at 11:39 PM, Anton Vodonosov <span dir="ltr"><<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Could you explain what do you mean by one table per platform?<br>
And in general I am interested to know what a compiler maintainer<br>
would like to see in reports.<br></blockquote><div><br></div><div>I meant that each of the rows could have a separate page. Currently it is quite complicated for me to see everything on my little laptop screen.</div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Would it be possible to distinguish between test failure and build failure? That would set up priorities straight.</div><div class="im">
<br>
</div>There is no separate test status for build failure (I saw on ECL test farm record build status and test status separately and considered but haven't decided to introduce it yet).<br></blockquote><div><br></div>

<div>It shouldn't be very difficult for your setup, I believe. When I use quicklisp for testing I distinguish two phases: building the library I want to test (this may produce errors) and then running the tests themselves (which produces the output you have right now).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Today you have 4 ECL version x 56 libraries = 224 test results. Lot for work to review everything.<br>
And we will add more libraries / more ECL versions. I came to a conclusion that a better strategy is not to review every test result, but to concentrate on regressions</blockquote><div><br></div><div>Regressions are indeed very useful, but probably more once the set of libraries that is working is larger. Right now it would be very useful to sort the libraries by dependencies: those that other depends on and fail will likely cause failures on other libraries themselves. Again, that should be programatically easy to do, given ASDF's tree of dependencies (or quicklisp's for that matter).</div>

<div><br></div><div>In any case, thanks for the great job you are doing!</div><div><br></div><div>Juanjo</div></div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br>

<a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>