[boost] Re: [1.33.0] Let's start preparations...

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
>> 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