|
Boost : |
Subject: Re: [boost] Review quality [ was stack trace review]
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-01-02 15:35:58
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk