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