-----BEGIN PGP SIGNED MESSAGE-----
Okay, this is it: please no more commits to the py3k branch for now.
Also, for the remainder of the time until final, please make sure there
is an issue for each change you want to make containing the patch
(which was already the case for almost all changes after rc1 anyway),
and assign the issue to me for sign-off after review.
Changes to the "What's new" are exempt, but I would love some volunteers
to read through the document and note any issues or typos.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Since there are no remaining blockers (real or deferred), the
py3k branch is now frozen for the rc3 release, and subsequently
will remain frozen until the final, unless critical bugs are
uncovered. Any checkin that is to be made must be made by either
me or one of the experts (Windows, Mac, What's New).
Thanks for your patience,
Since py3k has seen quite a few commits since rc2, I'd like to be
on the safe side and put in an rc3 this weekend, with the final
postponed by one week. (Just a heads-up, there shouldn't be
anything different for non-release-managers/experts as I hope for
a commit-less week).
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