On 08/04/2012 02:19 AM, Toshio Kuratomi wrote:
I suggest that you start by asking nicely what things need to be done
to
port those things to python2 and then go to work on doing them. Trying to
force a change via the Feature process is reversing the order of things.
Features don't exist to force other people to do work. Features exist to
showcase and coordinate the work that you are doing.
Right. Since I know Barry Warsaw, I got to see a bit of the way the
Ubuntu/Canonical folks went about this, and one of the big things they
did was to work with upstream projects to add Python 3 support. (e.g.
the dbus-python patches for Python 3 compatibility were mostly Barry's
work:
http://www.wefearchange.org/2011/12/lessons-in-porting-to-python-3.html)
One thing to watch out for is that once you start porting
applications, the
live images and install dvds will start requiring python3. If you aren't
careful, some releases may end up requiring both python2 and python3. This
is something that would need to be coordinated with the spins as well as the
applications you're porting to figure out what is okay as a size constraint.
You may end up having to maintain a parallel python3 branch for many
applications until all of the applications on an image are ported to
python3.
Wherever possible, it's *much* easier to go with a single codebase that
runs on both Python 2 and Python 3. The common subset of the two
variants ended up being much larger than originally expected. For pure
Python code, Armin Ronacher's "python-modernize" can help flush out
legacy constructs that will fail under Python 3.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane