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.
Christian
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers