Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk