Peter Dimov wrote:
Jeff Garland:
Let me put it another way. We will continue testing and fixing on the all compilers/platforms for which we have volunteers. The difference is, that we aren't going to hold the release up to ensure that less standard compliant compilers are all green. By reducing the number of platforms we can reduce the cycle time for developers to be sure changes are working.
I agree that dropping compilers that do not provide rapid testing turnaround will improve matters, but I'm not seeing the connection with the level of standard compliance or the number of the release platforms. The tests run in parallel, so 1 day is 1 day.
Simple -- if you write a standards compliant C++ library than porting to a 'closely compliant' compiler requires little to no effort -- very few macro hacks, etc. Of course there's still some differences with the newer and better compilers that can cause failures, but it's few a far between as compared to trying to port to a non-compliant compiler. So, focusing our effort on standard compliant compilers will save time for new libraries that are being added to Boost. Also, changes to existing libraries can move forward even if they break the non-compliant platforms -- again less work for the developers, less 1 day cycles to get the testing board all green.
Some platforms may prove problematic for other reasons, of course, but we can and should deal with that if and when it happens, not preemptively.
Again, we're not stopping the testing on these platforms just de-focusing developer effort on fixing any failure results for the 1.35 release. If a non-designated platform turns out to be highly compliant then we can certainly change the list at a later time. And again, it doesn't mean developers won't fix issues on those compilers/platforms...just that the release team isn't going to pester them about it or remove their code from the release because that compiler/platform is broken. Jeff