Re: 64-bit SGI account offer

> Disagree. It's just a verification. You can also more easy see when > something broke on a certain machine with a certain configuration. This > evening im going to take a look at the make-tests.php Well, there are only 3 possible test result states, FAILED,PASS or SKIP. If the test did not succeed we know it passed or was skipped for whatever reason. For the purposes of debugging I believe that data is for the most part meaning less. > > > The user should have the option to decide via a config-file to write > > > the xml to disk or to directly submit it to the webserver. > > > > Why involve XML into this? We already have a facility to submit > > test via a > > POST request to the QA team and if that fails, the results are > > written to a > > plain text file a user can read and if they want email manually to QA. > > But it's unreadable. I don't have the time and the pleasure to compare 9 > result-logs. It would be much easier to compare this via an web interface. > XML (or especially WDDX) could easily be used to send the results to a > website, store and in a database and write a interface to this database. > This has already be done (see > http://php.nohn.net/autotest-stats.php ) for > an example. It quite readable, it shows you the expected output and what really happened. I do not want to see run-tests become an overly complex thing that relies on multitude of modules and extensions. It is there for testing purposes, hence it should be very simple to avoid itself being prone to possible bugs. I did look at your site, and I personally I do not find that information output format convenient. In an email I see all the problem as well as the system information (phpinfo()), which may have had an effect on the test. With a web output I need to browse multiple pages (time wasted) to get the same kind of information. Given the small number of QA and bug solving personell we should make every effort to make sure that data is very easy to access, otherwise it is absolutely useless. Ilia