Martin Wille <mw8329@yahoo.com.au> writes:
Misha Bergal wrote:
Martin Wille writes:
[...]
- resource limitations at Sourceforge (e.g. the number of files there) My problem with SF is that do not have much of control over the environment there.
Yes, that's another problem.
- library maintainers don't have access to the testing systems; this results in longer test-fix cycles. I investigated this a little bit: the current licensing for commercial compilers doesn't permit to "access to the testing systems" by people other than the licensee (not so with free compilers). If somebody with more influence would make some kind of arrangement with a compiler vendors, we for one could try to give people reasonable free access to our test environment.
That'd be great.
I'm wondering whether companies that are both hardware vendors and compiler vendors would be willing to support testing of Boost by donating resources (hardware and compilers). However, legal issues would have to get examined closely. We can't make promises like "the next Boost version will support this compiler or that operating system".
Needs to be worked at. [...]
- changes which will cause heavy load at the testing sites never get announced in advance. This is a problem when testing resources have to be shared with the normal workload (like in my case). Can be alleviated by splitting testing vertically (by toolsets)
That currently would require to use several runner-ids, wouldn't it?
It is the the results format (not multiple runner-ids) that is a problem, right? If this is the case, would the following format eliminate your problems: Martin Wille Tue, 08 Mar 2005 10:00:22 +0000 Tue, 08 Mar 2005 13:00:22 +0000 gcc-xxx gcc-xxx gcc-xxx gcc-xxx gcc-xxx gcc-xxx gcc-xxx gcc-xxx
- test post processing makes use of very recent XSLT features. It is such an _enormous_ (trust me) pain to do without them. And it would take quite a significant effort to manage w/o XSLT.
Have databases been considered for storing the test results?
Briefly. I thought they would help a lot if we were to generate the results dynamically. In that case instead of pregenerating all results we would generate them in front-end on the fly. One of our main requirement for the Boost-wide regression log processor was to minimize environment requirements for processing and web site scripts. We didn't want the web front-end, because it would tie us to particular technology (PHP,CGI,Java or ASP.NET), which would reduce our hosting choices. The same goes for a database. Currently, the processing stuff (boost_wide_report.py) requires just Python, xsltproc and some stuff on IIS/Apache to do the on-demand extracting of files from zip results archive. -- Misha Bergal MetaCommunications Engineering