Hi,
I have 9 pending patches to fix Python 3 issues in Swift, but they
didn't get much attention yet. Most of these patches replace a pattern
with a new pattern to add Python 3 support in addition to Python 2 support.
https://review.openstack.org/#/q/owner:%22Victor+Stinner%22+status:open+project:openstack/swift,n,z
The problem is that these patches are long, and so it's common to get
conflicts. It takes me a lot of time just to rebase these patches.
Only "Replace dict.iteritems() with dict.items()" got a +2 yet.
I hesitate to simply give up on porting Swift to Python 3, to focus on
other projects which are faster to review my Python 3 patches
(ceilometer, cinder, glance, keystone, nova).
Maybe I took the wrong strategy for Swift. Instead of replacing a
pattern in the whole Swift project, I should maybe try to port tests one
by one to have shorter patches?
My last try fix "tox -e py34" in a single patch:
https://review.openstack.org/#/c/199034/
Practical issue: it depends on my pyeclib pull request that I sent 3
months ago...
If this Swift "Fix tox -e py34" patch is merged, my pyeclib pull request
is merged, and a new version of pyeclib including my fix is released, it
will become possible to make the gate-swift-python34 voting to avoid
Python 3 regressions. It should be nice milestone to start with shorter
patches.
What do you think?
Victor
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
