Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Rob Riggs (rob_at_[hidden])
Date: 2010-03-26 19:24:04

On 03/19/2010 09:49 AM, Vladimir Prus wrote:
> Daniel James wrote:
>
>    
>>
>> I'll reply to this properly later, I just want to say that we should
>> also take into account the difficultly we cause distributions. I was
>> surprised to see us mentioned alongside much more high profile
>> projects here:
>>
>> http://www.markshuttleworth.com/archives/290
>>
>> But I don't think it was a complement. We didn't pay much attention to
>> this post at the time, but probably should have:
>>
>> http://article.gmane.org/gmane.comp.lib.boost.devel/196669
>>      
> There's
> no doubt Debian folks or any other packagers will not be happy about 90 libraries
> on a separate release schedule.
>    

They deal with many, many more libraries for Perl, Python, Ruby, Java 
and others.  The major Linux distributions would not bat an eye at 90 
libraries.

Here are the results from Fedora 12:

$ yum list "perl-*" | grep -E "noarch|x86_64" | wc -l
1481
$ yum list "python-*" | grep -E "noarch|x86_64" | wc -l
423

Most of those Perl modules likely come from CPAN.  Apache alone likely 
provides 90+ libraries for the Java platform.

What the distributors (and users!) want from Boost is some indication of 
what parts are stable, what parts are under active development, and what 
are NSFW.  My guess is that the distributors might package up 1/2 - 2/3 
of Boost, depending on popularity, if they were available for individual 
consumption.

Speaking of Apache, the Apache incubator process would be a great 
process to adopt for Boost.  It gives projects exposure, a chance for 
major follow-on work to occur, feedback from users, and for interfaces 
to settle down before being blessed as full projects.  A similar process 
for Boost might address some of the developer issues and some of the 
user issues at the same time.

There is no way *Boost* could currently deal with 90 libraries on 
separate release schedules given the inter-dependencies that exist 
between the libraries.

Rob