Barry Warsaw wrote:
I think this is a case where PQM might have helped. Assuming the build/test would uncover these subtle bugs, the multiprocessing code would not have landed. You would then probably publish a branch with d t those (failing) changes and rally the help you needed to fix those problems. Then you'd try to land it again.
The workflow would have likely been very similar to what happened for this code, except that it would be happening on a branch, not on the mainline. Maybe no one would have been motivated enough to get them working if they weren't breaking mainline. The tradeoff is instability in the mainline and uncertainty as to whether the mainline is of high enough quality to release.
I suggest that we should use branches to a greater extend. New features or updates of existing code should happen on a branch. A branch must not be merged until it's tested on all major platforms (Linux i386, Linux AMD64, Mac OS X and Win32) and peer reviewed by another developer.
During my time as a Zope and Plone developer and at various XP sprints I've utilized the branch development and peer reviewing workflow with great success. I assume the majority of Python developers don't do branches because it's an expensive and annoying operation with svn. Well branching isn't so annoying but merging and keeping a branch up to date definitely is. Once we have a VCS with cheap branching and easy merging we should switch to branched development.