Boost logo

Boost :

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


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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at