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
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.
(I prefer to discuss here because launching a possible flamewar on