On Sun, 20 Mar 2005 18:19:33 -0500, David Abrahams wrote
I think it should also be available from an obvious link when you go to get information on or download the current release.
Sure.
Do we even have a way of tracking the check-ins?
CVS?
That might be a good first step. I notice that sourceforge seems to be generating some sort of email when I check-in, but I don't know of a way to subscribe to the changelist.
We can set up a mailing list for it to send to, if you want to see those. But I don't think that would solve the problem by itself.
I don't know of a CVS command that would give me all the changes to the repository in the last 12 hours (there may be one). So if something breaks and I didn't check anything in, I might want to find out who made the change and fire off a heads-up email to them. So I think the mailing list might have some utility. This might be particularly relevant to the folks running regressions b/c as some if they see a library start to fail it would be much more obvious who's to blame...
I agree with him about wanting to use the compiler to find breakage, but the problem is that his particular library is one that many libraries depend on. As a result, it really needs to stay stable during the release period to ensure that we don't have 2 days of downtime while something Boost-wide is broken.
If we could initiate tests on a branch by request we wouldn't have this problem; he could run all those tests before merging.
Yes, but there will still be some limit. If we are 3 days from release and the test farm is humming away on both mainline and the release branch we proably won't have infinate bandwidth to test developer branches. But I agree totally that regression testing on developer branches is a huge and powerful feature...
So I really think that we need to start thinking about a dependency analysis of Boost and an added freeze date for 'core libraries' that need to stay stable during the release process.
I'd really like to avoid that.
Why, what does it hurt? Core library developers just need to adjust their timeline thinking. Think of it this way. All releases have a certain cycle to them. Stabalizing the core is one phase. So the release timeline looks something like: -45 days core library freeze -30 days last new library added -15 days branch for release -2 days all code frozen (doc changes ok) Back in the ideal world, I'd like to see Boost releases become really inexpensive in terms of time. In combination with some of the other things we are discussing we should be able to normalize the process to the point where the length of the release timeline is very short -- I'd say 15 days or less. We have a long way to get there though... Jeff