2009/5/21 troy d. straszheim <troy@resophonic.com>:
That's true of course. And of course this has little to do with the practice of repeatedly testing and 'merging around' unmaintained, unreleased code.
Generally, it isn't that much of a problem, since most developers just deal with a couple of directories. It isn't great but for the most part we can just ignore most of boost. I suppose if you're working on a new build system you can't.
How about regression-testing a codebase that has a fighting chance of actually becoming a release?
Boost is a volunteer organisation.
You're stating the obvious; sorry if I'm irritating you.
Sorry, my mail was too negative. We get a lot of 'somebody should do something' emails. You are doing something with your cmake work, so I wasn't being fair at all. If that results in a better testing system and better modularization that could improve the situation massively - having a single tree for such disparate libraries that are developed at different rates doesn't help.
(BTW I didn't mean "you" above when I said "you're regression testing"). I'm just being careful, trying to establish how much of this is by design, and how much has just 'evolved' on its own...
It hasn't entirely evolved on its own. A few years back we the release and trunk branches were a complete mess (the current situation looks very clean in comparison). We cleaned up a lot of the conflicts and established the rule that changes had to be made to trunk and go through regression testing before being merged to release. Which has made things a lot better. It isn't ideal but it works a lot better than what we used to have which might be why we generally feel content. The problem is that we can't branch release from trunk - as we don't know what new stuff is release worthy. And we don't want to overwrite trunk from release as that might lose something and it would interfere with more long term development. Working on a branch is a nice idea in theory, in practice it turns out to be a pain since boost is so large, especially with subversion. And we really do need to get code into the regression testing system as soon as possible. With git it is a little better as you can create a micro branch and rebase it, but git isn't really in a state where most boost developers could use it. Modularization would help a lot. If you look at your summary of differences, many of them are in Boost.Spirit and Boost.Math which are well maintained and are perhaps long term changes that aren't ready for release yet. But there are a lot of small changes in largely unmaintained libraries - I think they just need people to go through them and clean them up. I think we are able to automatically identify which libraries most headers belong to, so a tool which summarized the unchanged headers might help. Anything which is left unmerged and untouched for some time would be a cause for concern. Daniel