On 10/14/17 6:09 AM, James E. King, III via Boost wrote:
Thanks that is useful! I'm still concerned about limiting the scope of reasonable testing effort and compiler support to reduce the amount of maintenance and test matrix systems for the project overall. It seems fairly clear from those test matrix results that msvc-7.1 and msvc-8.0 are no longer healthily supported by many libraries, and as previously stated both of those compiler suites are past end of support.
I think that result matrix is most useful when it doesn't have that many things in it, so folks can focus on closing down a release. I'm not sure if graying out the items will help identify problem spots. If there was a way to filter out certain toolset identifiers, on the page, that might solve that problem.
The current test matrix has a number of issues. First of all it doesn't display differences by variant, linkage, C++ version in a coherent and organized way. I made an attempt to address this with library_status described here http://www.boost.org/doc/libs/1_54_0/tools/regression/doc/library_status.htm... But what I would really like is to see our testing matrix upgraded to a testing results database and browser cube. So one would do something like: library_status -columns compilers=... or all, variant,linkage ... rows test or library_status -columns tests rows compilers ... or whatever I would also like to be able to easily post the result run from any machine, including my desktop to the common results database regardless if they were generated by boost build, CMake or even some other homebrew setup. That is, I would like to see test results posting design decoupled from any particular build system. Of course this would be a very ambitious project. On the upside, we have a lot of the pieces done or partly done or residing in current components like regression.py . Robert Ramey