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

Subject: Re: [boost] Review quality [ was stack trace review]
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2017-01-02 20:14:43

Robert,

I do agree with your points below about importance of tests and duties 
and ever-present risks associated with deployments of external libs. 
Still, I am not quite sure how it all stemmed from my fairly simple (and 
I thought non-controversial) view that the incubator had those risks 
prohibitively greater compared to the Boost proper. That is why I 
personally did not see the incubator being considered/evaluated for my 
particular projects and probably not taking off on a larger scale.

Accidentally, that incubator-related view of mine does not immediately 
seem related to the original "Review quality" topic. So, it might well 
be that I was first to veer off. :-) Apologies.

On 2017-01-03 09:56, Robert Ramey wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost