Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-03-19 13:12:44

Artyom wrote:

> 
>> 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.

Well, for 1.41, I have created a maintenance branch (/branches/maintenance/1_41),
which got some simple but important bugfixes. However, there did not
seem to be much interest. The effort to keep a maintenance branch is
close to zero, so if anybody wants it, we can surely create it for
all future releases.

> 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?

That is the problem I have also listed.. Generally, people won't even notice such issue.

> b) Are there any policy of bug-fixes in stable releases?

See above on the maintenance branch. I think we should have a mechanism to
deliver critical fixes to users immediately, but no officially accepted
mechanism exist.

> 
> 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.

Thanks, (c) and (d) seem like valid problems indeed.

- Volodya