From: Misha Bergal (mbergal_at_[hidden])
Date: 2005-03-08 22:42:53
Martin Wille <mw8329_at_[hidden]> 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
>> 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
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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk