Martin Wille <mw8329@yahoo.com.au> writes:
- bugs in the testing procedure take too long to get fixed I think all I can say on this one is said here -- http://article.gmane.org/gmane.comp.lib.boost.devel/119341.
I'm not trying to imply Misha or you wouldn't do enough. However, the fact that only two people have the knowledge and the access to the result collection stage of the testing process is a problem in itself.
That is worrisome.
- incremental testing doesn't work flawlessly That's IMO another "top 10" issue that hurts a lot.
It's a bit of a problem that when bjam scans for header dependencies it can't preprocess the files, so dependencies created by #include SOME_MACRO() don't get registered.
- lousy performance of Sourceforge - resource limitations at Sourceforge (e.g. the number of files there) This doesn't hurt us anymore, does it?
It hurts everytime the result collecting stage doesn't work correctly. We're not able to generate our own XML results and to upload them due to the SF resource limits.
We can get resources from OSL if we need them... once this discussion discovers what we need ;-) By the way, this discussion should really be moved to boost-testing. -- Dave Abrahams Boost Consulting www.boost-consulting.com