[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