Stephen Kelly-2 wrote
Paul A. Bristow wrote:
a situation where a lone worker was solely controlling a key library used by almost all others.
Isn't that exactly how boost is designed to work?
I'm not sure how was boost was designed - or evolved ( I suppose it depends upon one's religion). But I think that a major contributor to Boost's success is the fact that the boost "organization" (that's us) doesn't really design or take responsibility for doing anything but rather passes judgement on things that are proposed to it. The puts the onus on individuals to craft something that meets some sort of standards. Due to the features of human nature, ego, etc. .... these library are very much an individual effort - which is a good thing. It promotes conceptual integrity and makes for smaller, decoupled libraries. One thing we do is that once a library is accepted, it shuts the door to anyone proposing alternatives. I see the value in this, but it limits us also. Would it be a problem if someone were to submit an alternative serialization library for example. Certainly someone likes the library interface but might prefer one which is more C++17 friendly and header only. Is there any reason we couldn't have both - as long as they meet boost standards? (which I would like to see higher than they are). If we had statistics on library usage, we could drop accepted libraries from the "standard" distribution when they fall out of favor. I love the way boosts drives C++ forward by accepting things which no committee would ever design - like boost / spirit, asio, and other stuff. But the dynamism is only working for the intake of libraries. In my world, anyone dissatisfied with some aspects of the Boost Test could make boost test2 (or boost validate or whatever) which, if accepted, would be an competitor. If, over time, one fell in to wide disuse (lol - I couldn't think of a better way to say it), it would remain a boost library with it's imprimatur of excellence, but wouldn't be included in the default boost distribution. I would be effectively be supported - though in effect be deprecated. Of course if the author got on the stick and his library became popular again, the decision could be easily reversed. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/test-boost-test-owner-unresponsive-to-per... Sent from the Boost - Dev mailing list archive at Nabble.com.