[python-committers] PQM?
Christian Heimes
lists at cheimes.de
Thu Aug 14 15:51:59 CEST 2008
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
More information about the python-committers
mailing list