Re: [boost] trunk vs release

Subject: Re: [boost] trunk vs release
From: Daniel James (daniel_james_at_[hidden])
Date: 2009-05-21 12:01:11

2009/5/21 troy d. straszheim <troy_at_[hidden]>:
>
> 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