On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental.
Currently, there are some things in the release which are not explicitly tested. Basically, these are test tools such as bjam of boost build, boost book, and perhaps others. Including CMake in the release would be consistent with current and recent practice.
However, I believe the boost libraries could benefit by requiring that the same standards applied to libraries be applied to all tools delivered with the library. I see no justification for tools meeting a lessor standard than libraries.
In one sense this isn't a huge deal as - at least in the case of build tools - they pretty well tested as a side effect of being used to test other libraries. But I think boost would benefit by setting the same high standard for libraries and tools. This standard would state:
a) all released libraries and tools have been reviewed. b) all released libraries and tools are explicitly unit tested. c) all released libraries and tools meet some minimal standard for documentation and examples.
So any user of the release would know that
a) is it is meant to be used out of the box for production code. b) given the uniformly high standard to which all components are subjected, any failure, error, confusion regarding the documentation etc. is likely an error or oversight on the part of user and merits a more careful examination before raising the issue on the list. c) after consideration of b) above, any failure, error, confusion regarding the documentation etc. is unknown to boost developers and merits an error report.
This will make it much more efficient to use boost.
The alternative of having a policy of including expermental/untested/unreviewed code in the release is that every time the user has some sort of problem, he has to consider that the problem is not caused by him. Simple economics mean that he'll do the easiest first - query the list or assume its a known problem. Basically, once code that doesn't meet some standard is admitted, then every time a problem occurs, one has to consider the possibility that the code doesn't meet the normal standard and this takes a lot of time.
To summarize: a) set standards for all components - tools and libraries in the release b) insist that all components meet the same standard. c) tell users a) and b) above and this release is the best we know how to do at the time of release.
If one want's to create experimental "add-on" packages, that's fine - just don't package them in the release. These experimental add-on's can be on thier own track of development and be "mixed-in" at the user's discretion - assuming they are compatible with the public API of the libraries - which is another discussion we needn't go into there.
Robert Ramey
--Beman
Totally agree. An uniformed standard on coding, performance, compatibility and doc is important. B/Rgds Max