"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
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).
cvs diff -D "12 hours ago" -D now
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.
Not infinite; just "enough."
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?
Extra overhead; more to manage. I'd rather have an automated system that "just works" (yeah, right ;->)
Back in the ideal world, I'd like to see Boost releases become really inexpensive in terms of time.
Agreed.
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...
Yep. -- Dave Abrahams Boost Consulting www.boost-consulting.com