Mailman 3 February 2011 - python-committers

py3k frozen for rc2
by Georg Brandl 13 Feb '11

13 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. cheers, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1FNM4ACgkQN9GcIYhpnLB20wCfUHDP6xAy3jOj2egp+IsYhA8r fYkAnR5gSiXv79y7UXLH97zpcUMcAXHV =4g0D -----END PGP SIGNATURE-----

6 10

py3k frozen for rc3
by Georg Brandl 13 Feb '11

13 Feb '11

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, Georg

1 0

3.2rc3 on weekend
by Georg Brandl 09 Feb '11

09 Feb '11

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). Georg

1 0

Code Simplicity » Open Source Community, Simplified
by Steve Holden 08 Feb '11

08 Feb '11

I imagine many of you will have seen this, but it's worth over-posting to make sure everyone gets to see it who is interested. http://www.codesimplicity.com/post/open-source-community-simplified/ regards Steve

16 87

Create a Mercurial repository with a branch per issue
by Victor Stinner 04 Feb '11

04 Feb '11

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)

8 13