Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-11-21 10:00:44

On Fri, Nov 21, 2008 at 7:47 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> I agree that testing needs to be made more regular and thorough.
> However, IMO the universe of compilers and libraries is much too large
> --- and in some cases, the software is too expensive --- for us to check
> code with new versions of *all* compilers and *all* libraries.  We need
> to select a subset against which we'll test.
>

I think we're forgetting here that although BoostPro offers commercial
support for Boost releases in the form of consulting and enterprise
support, it's all really a matter of how much volunteers can really
give as far as committing resources is concerned.

For one thing us users of Boost have our own software that we take
care of -- rather than relying on the open source community around
Boost to perform the testing for us, we should be doing our due
diligence and make sure that *if* or *when* we do decide to upgrade
whatever we use (be it Boost, the compiler, some third party library
we use with Boost, build tools, continuous integration environments,
etc.) that we do our own testing. The least we can do is when we do
find problems, we report them and/or submit patches to fix the
problems.

Although the Boost Open Source Model is not the same as other models
-- i.e. what goes in/out of a library is determined by the library
maintainer and not the whole community at large -- it still is a
volunteer effort that will benefit from as much feedback as us users
can give. We can either keep changing the model, or we can work with
the model we have and continue moving forward and getting bugs
reported then fixed for everybody's collective success.

I for one know how hard it is to get other people to use Boost -- but
thankfully the quality of the implementation of the libraries
contained and that we've eventually used have dispelled the initial
insecurity other people have with the collection. Given that it's
peer-reviewed and is largely well-implemented, it's not hard to show
people how much readable+efficient code is when using the boost
libraries. What's hard to justify though is the notion of an upgrade:
the question "why do we have to upgrade if it's not broken?" comes up
and is really hard to answer.

At any rate, I for one am still stuck with Boost 1.35 and GCC 4.1.2 --
and moving to Boost 1.37 and a newer GCC may be a problem, but there's
nothing stopping me from trying it out for myself and seeing/verifying
for myself what broke or what improvements/regressions I do get if I
do upgrade. We all want to have well tested code, but the best tests
we can run/write are those tests that actually test the software we do
write -- because only these tests are the ones that really matter in
the context of the software we are writing and in deciding whether to
upgrade the libraries we use or not.

Just my $0.02 worth.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.