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

From: Martin Wille (mw8329_at_[hidden])
Date: 2005-03-08 11:10:11

Misha Bergal wrote:
> Martin Wille writes:

[...]

>>- the code-change to result-rendering process takes too long
> 
> 
> We are working on result-rendering process part. We recognize that
> this has been a big bottleneck in the past and hopefully have
> significantly improved it.

This is good news!

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

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

>>- test post processing has to work on output from different
>>  compilers. Naturally, that output is formatted differently.
> 
> 
> Testing needs a better support from Boost.Build. Till that is
> implemented we will depend on parsing the bjam output.

Agreed.

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

Regards,
m