Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-03-21 08:58:10

Andrey Semashev wrote:
> On 03/21/2010 12:24 AM, Vladimir Prus wrote:
>> Andrey Semashev wrote:
>>
>>> 3. Monolithic design.
>>> =====================
>>>
>>> This matter has already been discussed, and others have made the
>>> suggestions, so I'll just express my thoughts of improving things.
>>
>> Could you clarify what exactly is the problem with monolithic design?
>> Is that merely that "Boost is too big" and it makes it harder to
>> add it as dependency for a project?
> 
> As a user, I constantly find myself excluding parts of Boost from 
> building. There are many header-only components I also don't use. 
> Overall, my estimations is that I use no more than 50% of libraries. So 
> I want to be able to exclude the unneeded part.

Are you concerned about disk space of sources, disk space of build
products (can be easily skipped already), download size, or something
else?

> As a developer, I would like to be able to ship releases as often as 
> needed, not necessarily bound to the current release schedule of Boost. 
> I also think that the monolithic design limits the appearance of new 
> libraries in Boost, as it implies the same quality standards on the well 
> established libraries and the new coming ones.

Well, it's possible to ship individual releases already, no biggie -- users
would just have to rm boost/component and libs/component and unzip new
release on top of that.

> Some performance problems of SVN and Trac have been identified by users. 
> I think, they resulted from centralized storage of Boost artifacts 
> (which are the source code and tickets).

I believe they stem from current server hosting both. For example, KDE is
a couple of orders of magnitute larger than Boost, and I never noticed
significant performance problems with SVN.

> Some have concerns about testing results turnaround. Since now the whole 
> Boost should be tested as a whole, that problem will grow bigger over 
> time. A modular approach would allow each tester to run tests only for 
> one or several libraries and thus produce the results more often.

OK.

- Volodya