From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-07 12:23:32
Beman Dawes wrote:
> A draft "Development and Release Practices" document is up on the
> Wiki:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_And_Release_Practices
>
> Comments welcomed!
I think that the Trac wiki is a better place for this document.
Weak points:
1. Merging from trunk to release. This is critical for the success of the
whole scheme, but the details are still to be worked out. It's not clear
whether tools can help much since we're talking about merges across two
independent parallel branches without a close common ancestor, but I can be
wrong.
2. Testing core libraries on branches. Not clear how or who, or even whether
at all.
3. Trunk. Unclear what would prevent the current wild west syndrome, except
for the continuous testing; but if this is all that it takes, why didn't we
institute this policy earlier?
Some comments on core libraries:
"Note that the requirements for being release-ready are transitive; if a
library has dependent libraries, it isn't considered release-ready if it
breaks any of those dependent libraries."
This is sensible but it can prevent progress if these failures are caused by
the dependencies rather than the core library. Two arbitrary shared_ptr
examples: (1) the serialization library in 1.32 relying on implementation
details, (2) Spirit using the long deprecated make_shared spelling of
weak_ptr::lock.
A failure downstream is caused by either (1) insufficient test coverage in
the core library, (2) a "bug" (broadly speaking) in the dependency. We still
don't have a proper policy to address (1). We don't ask people to contribute
tests, and we don't (in general) add tests when we fix bugs.
Looking at the big picture, all Boost libraries are core, because the World
depends on them. The World however doesn't get to receive the preferential
treatment that non-core Boost libraries enjoy; it relies on bug reports. I'm
not saying that this is a good or bad thing, just a food for thought.
Finally, a philosophical point.
I'm slowly coming to the realization that the problem we're having is not
caused by lack of process or lack of tools. It's caused by the fact that
release management (at this point) is a full time job.