Meanwhile other libraries like Boost.Serialization (and consumers of same) also make their own assumptions about things like endianness and type structure, which may not matter too much in isolation but becomes very important if you're intending to use it as a portable network or disk format.
I think then it is important for the libraries in which some of the code is tailored to a platform/architecture to test on other platform/architectures than Intel, but for the large number of Boost libraries which have no direct dependencies on a platform/architecture I do not see that it is of much importance. Simply because library XXX uses Boost.SmartPtr does not mean that testing on ARM is going to show anything of use for library XXX, which testing Boost.SmartPtr on ARM would not itself show.
Fully agree with the first point, as usual: Every branch needs to/should be tested. However usually bugs show up in complex scenarios, so testing the downstream lib might show up bugs which the author/maintainer of the lower-level lib didn't think about. So there is still worth in testing that. Weekly is likely enough to not burn to many resources. However the question still is: How/where can those (low level) libs be tested on other hardware? Travis is basically dead for us and setting up CI is hard (see prior discussion), so testing Boost as a whole on many archs, OSes, ... might still be the easiest solution as it means a single setup to be maintained (see the integration tester approach, which I'd say needs some love) Alex