Re: [boost] The problems with Boost development

Subject: Re: [boost] The problems with Boost development
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2010-03-19 09:32:25

On 03/19/2010 04:14 AM, Vladimir Prus wrote:
> Hello,
>
> in a recent post, Dave listed a few things that he thinks are wrong
> with Boost development, at present, quoting:
>
> 	I know I'm not the first person to notice that, as Boost has grown, it
> 	has become harder and harder to manage, Subversion is getting slow,
> 	our issue tracker is full to overflowing, and the release process is a
> 	full-time job.
>
> It seems to be important, right now, to discuss whether this problems are real,
> and what problems are most important.

I have to admit that I'm not very fond of this attitude that focuses on 
tools, rather than process. I don't think a switch from Subversion to 
Git in itself will solve any problem. (In fact, the constant focus on 
support tools takes away attention from what I consider the real issues, 
so it hinders progress.)

However, the suggested change implies more than a switch of support tools...

>   So, I would like to ask that everybody
> who is somehow involved in *development* -- whether in writing code, triaging bugs,
> sending patches, or managing thing, list three most important problems with Boost now.
> Please keep the items to a sentence or two, so that we can easily collect the
> problems.
>
> Here's my take:
>
>      - Unmaintained components. Many authors are no longer active, and we have
>        no procedures for taking over.
>    

I think this is symptomatic of an underlying problem with boost's 
mission: More and more components are added to boost, yet its mission 
statement as well as infrastructure and process don't scale. A couple of 
months some of us suggested a change of mission, for boost to become 
something akin to the apache foundation, i.e. an umbrella organization 
for (mostly) independent projects.

While I don't think Dave's current work addresses that issue directly, 
it seems it may be a good step into that direction. (A technical step, 
but technical issues are always the easiest to solve.)

I can also see that one of the fallouts of this modularization is that 
components will live or die with their individual communities and 
maintainers. They won't be dragged along with a huge monolithic project 
any longer.

>      - Reviews that are getting rare and, IMO, less interesting then before.
>    

I'm not sure that this is a problem. If there is enough interest into a 
new component, enough people will eventually get together to get things 
done. If things stall, it more often than not implies that there is not 
enough interest.

>      - Turnaround time of test results
>    

Definitely true. By componentizing things that will improve, though, 
since each tested component may rely on well-defined prerequisites, so 
these don't need to be built each time. It also makes testing much more 
attractive, since it requires less resources.

Regards,
         Stefan

-- 
       ...ich hab' noch einen Koffer in Berlin...