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.
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
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,
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.
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.
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
R. David Murray www.bitdance.com
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.
Tarek Ziadé | http://ziade.org
-----BEGIN PGP SIGNED MESSAGE-----
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!
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:firstname.lastname@example.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/
-----END PGP SIGNATURE-----
On 07/04/2010 11:30, anatoly techtonik wrote:
> There is still a serious regression in zipfile module:
> And I would really like to see my issue with difflib tabs committed: =/
The zipfile issue looks like it could be fixed for beta 2. Not so sure
about the difflib one.
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.