[python-committers] PQM?
Christian Heimes
lists at cheimes.de
Thu Aug 14 15:51:59 CEST 2008
More information about the python-committers mailing list
Thu Aug 14 15:51:59 CEST 2008
- Previous message: [python-committers] PQM?
- Next message: [python-committers] PQM?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [python-committers] PQM?
- Next message: [python-committers] PQM?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the python-committers mailing list