|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-03-21 03:30:37
"Jeff Garland" <jeff_at_[hidden]> writes:
> On Sun, 20 Mar 2005 22:17:00 -0500, David Abrahams wrote
>> > 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
>
> Thx, that's handy to know...
>
>> >> > 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 ;->)
>
> Well, I don't see any overhead or any more to manage.
Well, according to your own post, there would be "a dependency
analysis of Boost and an added freeze date for 'core libraries' that
need to stay stable during the release process," "core library
developers just need to adjust their timeline thinking", and there's
an additional step in the release process called "core library
freeze."
> We don't have to keep running some tool. We pretty much know what
> the core libs are. Make it policy, tell the developers when they
> need to freeze and trust they will observe it. If they don't and
> break the build well, they will face the wrath of the rest of us. I
> don't see why we couldn't make some reasonable agreement like
> this...
We could. I thought we sorta did make such a tacit agreement. But
it's always nicer when processes allow us to avoid such restrictions.
Well, you may have a point anyway; any change that's likely to cause
all tests to rebuild should be minimized late in the release cycle.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk