Re: [boost] Review quality [ was stack trace review]

Subject: Re: [boost] Review quality [ was stack trace review]
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-01-02 17:56:10

On 1/2/17 1:48 PM, Vladimir Batov wrote:
> On 2017-01-03 07:35, Robert Ramey wrote:
>> On 1/2/17 12:08 PM, Vladimir Batov wrote:
>>> ...
>>> 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 guarantee.
>
> Oh, come on. Of course, nothing in life is guaranteed. I can't guarantee
> I wake up tomorrow morning. But surely we all understand what I was
> trying to say. Is there really anything to debate/discuss here?

Hmmm - actually there is.  If you use a boost library, there's a real 
world chance that it may stop working in the future.  This could occur 
because you upgrade your compiler or because someone "improves" the 
official version so that it doesn't work for you any longer. Of the 
course it's much more likely for something like this to occur on some 
other library - in the incubator or otherwise.  You seem to suggest that 
this is not a problem with boost libraries while it is with others.  My 
view is that it's a problem with all code and libraries.  It just that 
due to a higher standard, it may be much less of a problem than it its 
with boost libraries.

But my view is that this concern never goes away and this fact should be 
built in to the development procedures of any application which depends 
on boost or any other library.  I don't think that depending on boost or 
on some component in the incubator or anywhere else is all that 
different.  I trust no one.

> I simply described the "real-world" project/product I am involved in.
> I've been doing it for quite some time and as far as I can remember all
> those "real-world" projects were using external libs and Boost has
> always been one of them. Forgive my saying but to say "I do not think a
> real world product can depend on anything outside it's own organization"
> seems very much out of touch with this very real-world... unless I
> misunderstood/misinterpreted it.

Let me clarify.  Of course we rely on externally produced code.  But if 
you ship it, you still have to be responsibility for it.  The only way 
you can do this now is to run the tests yourself.  I realize that people 
don't do this and I maintain that they are wrong not to do it. But if 
one accepts the view that he should run the tests on every library he 
includes in his own product, than the distinction between using a 
library review or in the incubator or anywhere else goes away.

> It appears obvious to me that an external lib (local copy or not) is outside of my control...

Agreed.

> unless I am prepared to take responsibility of maintaining the lib... which is not an option.

Unfortunately, you can't evade responsibility for the promises made for 
your final product.  Hence you can't evade responsibility for the 
functioning of the libraries you use.  Currently, the only way you can 
credibly claim you've fulfilled those responsibilities is to run tests 
on the libraries.  Libraries in boost and in the incubator are required 
to have tests (unlike any other source code collections). So this is 
possible in either case.

> With Boost that risk is minimal (practically non-existent); with
> incubator that risk is quite high. Others might disagree.

Certainly one would hope that libraries in boost have fewer bugs.  But 
since I believe that all code should be tested by myself before I ship 
it as part of a product, I can't accept/reject libraries on a case by 
case basis.  This is what I recommend that anybody do.

Sort of off-topic.

 > unless I am prepared to take responsibility of maintaining the lib... 
which is not an option.

Actually it IS and option.  Take a look at the Boost Library Official 
Maintainer (BLOM) program.

If you really depend on some library which no longer has a maintainer, 
Your company can take on that responsibility and gain some benefits 
besides.  The theory is that since you have to run tests anyway and 
perhaps apply bug fixes in the normal course of your work, you might as 
well take on the job officially and get and inside track in getting your 
fixes into the official version and maybe some free promotion/publicity 
for your organization.

Robert Ramey