Re: [boost] Development and Release Practices

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.