Beman Dawes wrote
It comes down to resources. I suppose if people really care about older compilers, they will be willing to contribute testing.
I still think a platform guru would be a useful function. This Person would run the tests on his local resources for a particular Platform and help with issues on that platform. Such a person would Have similar status to that of a library maintainer.
Say a library now covers 100 test cases spread out among five test programs. I'd like to see those five programs refactored into one program, still covering the 100 test cases. Or even adding more test cases. A single program would cut the overhead, including the human overhead.
I would strenuously disagree with this idea. In some cases it would result in a truly humongous program. When I included a test of this nature with my submission last year it was criticized for the above reason - rightly so in my opinion. There are lots of other problems besides. Suppose a test case doesn't compile - then none of the other tests are run. I'm still convinced that the problem with the release process is rooted In developer's desire to include features directly into release "heaven" Without having spent time in development "purgatory". Is_abstract and Autolib come to mind. The branch was announced approx 1 november. The autolib document is dated 26 November. Can't someone just monitor the state Of the development tree and when it looks pretty good say "We're branching today - nothing but bug fixes in the release". The current process is so Painful and takes so long that developers feel under pressure to get the Latest great feature in now because if not its going to take 6 months for The next one. Under this proposal, releases could be more frequent and In smaller increments. After all what's the point of running the tests on The development tree on a daily basis if its going to be more or less Bypassed under pressure for a release? Robert Ramey