Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-03-19 13:04:14

> On one hand,
> we have problems that are perceived on the developing side.
> On another hand,
> we have problems on the using side -- where lack of any API
> or ABI stability
> is surely an important concern -- but solving that concern
> actually requires
> more work from developers, and even, I think, more
> centralization. There's
> no doubt Debian folks or any other packagers will not be
> happy about 90 libraries
> on a separate release schedule.
> 
> - Volodya

I think this is very important point. Boost developers are very 
concern about the amount of work required to maintain the software,
but the question, is non-maintained library should be a part of Boost
at all?

Such huge code-base may become real mess when it is so widely deployed.

Let's take a look on a simple example of bug in UUID:

   https://svn.boost.org/trac/boost/ticket/3971

This bug causes quit not so unique IDs can be generated. This has
very bad security concerns that may cause in some software for example
guessable session ids.

Bad, very bad bug. Security bug. Solution? Upgrade to Boost 1.43 when
it is released (with hopefully fixed bug).

But lets go to the package maintainers of Linux distributions like
Debian:

1. They can't upgrade Boost version because many programs depends 
   on specific Boost version and it can't be transparently upgraded
   because Boost does not provide neither ABI nor even API compatibility

2. Boost does not release any backward compatible version with
   at least security bug-fixes. 

3. Package maintainers should manually backport all fixes to 1.42 
   because they have to provide secure software.

That is **bad** really **bad**. More then that, I even do not sure
if any of maintainers are aware that this issue should be fixed.

And this is not distributions issue, many companies stick with 
specific versions of Boost because upgrade may cost too much.

Now, generally the bug I pointed at is not so bad, it has simple
fix (fixed in trunk) and it even does not break any compatibility.

But:

a) What would happen if this issues happens in some unmaintained library?
b) Are there any policy of bug-fixes in stable releases? 

So there are two major issues I see with current development:

a) Boost releases should be more modular -- probably single trunk is
   bad idea.
b) Boost should support backward compatibility at some level and incude
   some maintenance of existing stable libraries.

Another point I had figured from reading reviews of the libraries
recently was:

**Very few reviewers actually do the code review!** Most of them
look into API usefulness, documentation of the library but only 
few of them read the actual lines of code. 

**This is bad.** For a long time period I was sure that Boost has
high quality libraries because may eyes look on them and so all bugs
vanish... But it seems to be different.

And if we take a look on the situation where:

a) Boost is considered high quality set of libraries.
b) Boost is very common library and every 2nd C++ project uses is.
c) Boost is not backward compatible even and API level.
d) Boost does not maintain stable releases.

Boost may become a library that when you are using it you are
exposed to high risks.

My $0.02
  Artyom