On 1/2/17 12:08 PM, Vladimir Batov wrote:
On 2017-01-03 06:24, Robert Ramey wrote:
On 1/2/17 7:41 AM, Paul A. Bristow wrote: ...
It would lead to better (and less acrimonious) reviews because we are not expecting perfection from day one.
FWIW - I don't think the reviews are all that acrimonious.
I have to site with Paul here as from what I've seen people do tend to expect everything on a plate from the set-go.
Too few people are reviewing 'real-life' usage. We need more users and that won't happen until we have a two-stage acceptance process.
Well we sort of have a two-stage process now.
Stage I = inclubator Stage II reviewed
The problem with the incubator IMO is that it does not provide any guarantee whatsoever that the library will be accepted/around/maintained in the future.
No one - not even boost - can make such a guarentee.
The deployment requirements might well be different for other people but my situation is that we simply cannot include an external library/dependency without such a guarantee.
I do not think a real world product can depend on anything outside it's own organization. This is the motiviation behind open source code.
The burden/impact of retiring/replacing a no-longer-supported library is likely to be unacceptably high.
Here is the way a Boost - or any other library should be used. 0) determine that a library is suitable to one's sitation 1) clone the library(ies) to one's local system. 2) If the libraries require building - build them 3) run tests on all libaries used. 4) build and link product/application 5) run application tests On "upgrade" of libraries or tools 1) update some libraries which need it 2) run tests on all libraries 3) re-build ap and re-run app tests So in no way should you be depending on something outside of your control. You should depend only on your local copy. This is true for any library accepted into boost or not!!! Now - I believe that library users do not run the test suites of the libraries they use. I believe this because no one in 14 years has complained about a serialization library test failing other than on the the boost test matrix. This is very, very shortsighted. Of course this is not just boost but everywhere. Test systems, including boosts, do not make this easy. It's a big problem for code quality. So short answer - do not depend on code that you do not test and keep a copy of on your own system. Do not do this regardless of where it comes from boost, the incubator or anywhere else. Then there is the standard library which compiler vendors send. They don't include a test suite - or even post a test matrix. Actually, I think they just use Boost to test their compilers - oh well. Robert Ramey