Beman Dawes <bdawes@acm.org> writes:
At 11:16 AM 2/11/2004, David Abrahams wrote:
If fixes aren't forthcoming for libraries that many other Boost libraries depend on, it delays testing on the other libraries.
Was that really a factor in this last release? Which libraries were delayed, and which fixes weren't forthcoming?
Iterator adaptors and type traits hurt a lot when they break.
Sometimes it takes awhile to figure out exactly what the problem is, too. For example, a change around January 16 caused VC++6.0 to ICE on several libraries. It didn't get fixed until the 26th, because it took time to realize where the fault lay.
I don't believe that the vc6/iterator_facade interaction caused any significant delays in testing other libraries; they were working fine, then they stopped working, and then they were working again.
IIRC, it got fixed the same day once we had figured out what change actually triggered the failure. Earlier in the release cycle, it took a while to get the auto link stuff working on all compilers. The release manager can only focus on so many things at once.
Sure; this shouldn't be up to the release manager. It's simply too much work and too error-prone. An automated system can identify precisely which checkin is responsible for breakage. Why leave it up to the release manager to notice the problem, and go back to do a laborious binary search, then harrass other people to deal with the problem? -- Dave Abrahams Boost Consulting www.boost-consulting.com