I have infrastructure built to do portability testing. It is a lot of changes, flexible, and turned on by command line switches. I know this doesn't help the current emergency, and I'm buried in chasing down bugs in the portable archive that I've found since I can now give it the full battery of serialization tests, and since I need to deliver this archive type ASAP, I can't switch to trying to do something intelligent about overall testing time within serialization. I am collecting ideas, and trying to refactor things as I go to prepare for this "something intelligent". But for now, maybe switch from carpet bombing to running only polymorphic xml archive (static), and non-archive-specific tests? It's a quick hack to the Jamfile, would cut the run time down by 1/6 or so and still get pretty good coverage. Testers could also get immediate relief by running with -sBOOST_ARCHIVE_LIST=xml_archive.hpp to get the same effect. (Apologies if that's obvious.) -t David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
I should note that the serialization library changes only very infrequently - maybe once every few weeks.
I would question re-runing the serialization library tests just because something that the serialization library depends upon changes.
We can talk about global policy changes after you fix the emergency. It's a lot harder to change the way we do testing and the rest of our infrastructure than it is for you to simply reduce the number of tests being run.
Please do what's required to bring the overall Boost testing time back down to something reasonable.
A main cause of this problem bjam dependency analysis re-runs all tests on Library X even if library X hasn't changed.
No it doesn't.
To reiterate:
Anything that makes it very difficult and/or expensive for a tester to complete a testing run needs to be fixed rather urgently.