Hi,
When a patch is attached to an issue, it is usually a patch for the last stable release or to trunk (2.7 or 3.2 trunk). The problem is that latter the patch doesn't apply to trunk anymore and the author have to update its patch. Sometimes, we ask to update a patch six months or one year after the creation of the patch. It is difficult to update big patches.
It would be nice to create a branch for each issue (or each attached to an issue?), so we can test the patch in the branch and work on the patch without having to update the branch to trunk. If the patch has many versions, we keep the history of the changes, and at the end, it is easier to update the patch to trunk (e.g. rebase the branch).
If the buildbots are able to checkout this branch: we can also test directly the patch and automatically post the result on the bug tracker. If it is a problem with security (a patch can execute arbitrary commands), this service may be reserved to core developer and the action would be manual.
I hope that it will help to manage issues like "Regexp 2.7 (modifications to current re 2.2.2)" (issue #2636) which has ~73 files attached, most of them are new versions of the huge regex patch, on an history of 2 years... But I am not sure that the author of the 73 files will use Mercurial, so we should so something to simplify the usage of Mercurial in this case.
I heard somewhere that some projects are already doing exactly that (create a branch per issue), but I don't remember which projects. We should learn from these projects.
Victor
(I prefer to discuss here because launching a possible flamewar on python-dev)