Mailman 3 April 2010 - python-committers

branches and merging
by Steven Bethard 06 May '10

06 May '10

I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now. Thanks, Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

19 52

When do we stop automerging from trunk to py3k?
by Larry Hastings 29 Apr '10

29 Apr '10

Pardon my general n00bishness, but I crave knowledge. IIUC currently if you have a checkin in trunk that you *don't* want merged into py3k, you must svnmerge block it in py3k. Otherwise it will be automatically merged at some point. My question is: when will we stop doing that? I assume that as time passes trunk and py3k will continue to drift further and further apart. My guess is that more checkins are blocked than are allowed through. So when will we stop the automerging? Or is this question a sign of a more fundamental misunderstanding? I'm afraid I have to tell you even I really just don't know, /larry/

7 9

Blocking commits to 2.6
by Georg Brandl 26 Apr '10

26 Apr '10

Hi, to make my life easier, I'd like to block all unmerged commits in 2.6 that nobody will merge anyway. I use ``svnmerge avail --log`` to find out which commits I have to merge, and with the current number of unmerged commits it is taking longer and longer. Does anyone else use svnmerge integration info on the 2.6 branch? Please speak up, so that I don't mess up your workflow. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

4 3

Proposing Tim Golden as a Committer
by Michael Foord 20 Apr '10

20 Apr '10

Hello all, I would like to propose Tim Golden as a Python committer. He has been involved in Python for many years, is a capable Windows guy, and has submitted many patches / documentation fixes - particularly for Windows issues. He may need a mentor, but here are many issues that he has contributed patches for: * Tests for test.support.unlink on windows) http://bugs.python.org/issue7443 (open) * mmap patch here: http://bugs.python.org/issue2733 (open) * subprocess patch here: http://bugs.python.org/issue2304 (open) * bdb documentation http://bugs.python.org/issue1136 (committed) * print media stylesheet for Sphinx docs http://bugs.python.org/issue1555 (committed) * distutil.test_util issue http://bugs.python.org/issue5472 (committed) * multiprocessing build fix http://bugs.python.org/issue3050 (committed) * Windows msi missing file http://bugs.python.org/issue5470 (committed) * msi.py copies non-existent files http://bugs.python.org/issue5721 (committed) * with lock fails on multiprocessing http://bugs.python.org/issue5261 (committed) * _winreg remaining in test_winsound http://bugs.python.org/issue8385 (committed) I skipped a bunch of further committed docs patches. I've known Tim for a while (although not well) and consider him an easy to get on with and straightforward guy. Having contributed patches for so long I'm sure he knows our processes well. At the very least we should grant Tim tracker privileges as he frequently responds to issues. All the best, Michael Foord -- http://www.ironpythoninaction.com/

5 5

Proposing Giampaolo Rodola' for commit access
by R. David Murray 17 Apr '10

17 Apr '10

I would like to propose Giampaolo Rodola' as a committer. Giampaolo has been around the community for several years, has made valuable contributions on the tracker, particularly in the areas of ftp, asyncore, and network services in general (he is the principle author of pyftpdlib), and has had a number of patches committed, including the new FTPS support in ftplib. I'm willing to mentor his commits while he gets up to speed with our processes. (Frankly, I was surprised to discover that he wasn't a committer when he inquired about being put in maintainers.rst as an expert for ftplib.) -- R. David Murray www.bitdance.com

3 2

py3k vs trunk branches
by Tarek Ziadé 13 Apr '10

13 Apr '10

Hello, I couldn't find anything relevant on this topic in the archives so.. : Since the 2.x line is now feature frozen (since 2.7 is the last 2.x release and we have reached beta), most new developments will start in the py3k branch. I was wondering if it wouldn't make sense to rename the current trunk to /py26 and /py3k to /trunk. Although I am not sure if this is relevant with the work done on mercurial side. Regards Tarek -- Tarek Ziadé | http://ziade.org

3 2

trunk unfrozen
by Benjamin Peterson 11 Apr '10

11 Apr '10

Commit away! I look forward to seeing more green buildbots for the next beta. -- Regards, Benjamin

1 0

trunk now completely frozen
by Benjamin Peterson 11 Apr '10

11 Apr '10

Time to release the first beta. -- Regards, Benjamin

1 0

pybsddb 5.0.0 integration and 2.7beta1 schedule
by Jesus Cea 08 Apr '10

08 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oracle just released Berkeley DB 5.0.21, with features like SQLite façade. I am now testing pybsddb 5.0.0, that supports BDB 5.0.x. My original plan was to delay integration of pybsddb 5.x.x for 2.7.1 release, but Larry Hastings has a (sensible) request to migrate pybsddb from CObject to Capsule for 2.7.0. Current pybsddb 5.0.0 already contains that change. I am reluctant to integrate the code change before beta1, because although it should be transparent I don't want to risk a red buildbot, even for 20 minutes, so close to beta1. Integrating it between beta1 and beta2 would be riskless, but it would break API compatibility (because the CObject->Capsule) change. I don't know how many people depend of the pybsddb C api, although I think that very little. What should I do?. When is the beta1 window closed? PS: I would need a couple of hours for integration, but beware timezone! (Spain :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS7t/z5lgi5GaxT1NAQL1VAP+LxE4TdHnS9hJpMj3q3GZAKz5c8ho8p2U mRpyMmIC7y9OUk5uLQYrYdGpIVVZgrCi47+Oo77lxV4tDHbbHbWXxCZcX5P1QosK HyKYVGS3nYc25WGgQvmGCtmw9LTLhiF24NHQtyzQp7LvPgCJu/OLlILaBCuYs/xX LxRJV0c9OxU= =pv/P -----END PGP SIGNATURE-----

5 7

Re: [python-committers] [Python-Dev] stabilizing for a release
by Michael Foord 08 Apr '10

08 Apr '10

On 07/04/2010 11:30, anatoly techtonik wrote: > There is still a serious regression in zipfile module: > http://bugs.python.org/issue6090 > > And I would really like to see my issue with difflib tabs committed: =/ > http://bugs.python.org/issue7585 > > The zipfile issue looks like it could be fixed for beta 2. Not so sure about the difflib one. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

2 1