Martin Wille <mw8329@yahoo.com.au> writes:
David Abrahams wrote:
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
[...]
I'll make a start, I hope others will contribute to the list. Issues and causes unordered (please, excuse any duplicates):
From my side, I would like to comment on some of the raised issues (this is not a rebuttal, most of the comments are about how the problems got already resoved or can be resolved with "a little help from our friends" :-) )
- 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.
- 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.
- between releases the testing system isn't as well maintained as during the release preparations.
Well, that's because in 1.32.0 timeframe a lot of effort went in the releasing the release and creating the testing tools to ensure the adequate quality of it, and it's been done by the same group of people, who obviously need time to catch up with other things they have.
- 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.
- 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)
- becoming a new contributor for testing resources is too difficult.
http://www.meta-comm.com/engineering/regression_setup/instructions.html (Of course this needs to be easily accessible from main boost site)
- post-release displaying of test results apparently takes too much effort. Otherwise, it would have been done.
http://www.meta-comm.com/engineering/boost-regression/1_32_0/developer/summa... (Of course this needs to be more easily accessible from main boost site)
- 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.
- 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.
- XSLT processing takes long (merging all the components that are input to the result rendering takes ~1 hour just for the tests I run)
Hopefully, not anymore. We merge all results in less than 30 minutes now.
I'm sure testers and library developers are able to add a lot more to the list.
Thanks for constructive feedback. -- Misha Bergal MetaCommunications Engineering