From: Robert Ramey (ramey_at_[hidden])
Date: 2004-02-12 15:56:49
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk