23 May 23:23
Ubuntu Server Team Meeting Minute 20120522
Serge Hallyn <serge.hallyn <at> canonical.com>
2012-05-23 21:23:52 GMT
2012-05-23 21:23:52 GMT
Meeting started by s3h at 16:01:01 UTC. The full logs are available at http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-22-16.01.log.html . == Meeting summary == *Review ACTION points from previous ''LINK:'' https://blueprints.launchpad.net/~ubuntu-server/+specs?role=drafter (Daviey, 16:04:06) ''LINK:'' https://blueprints.launchpad.net/~james-page/+specs?searchtext=servercloud-q&role=assignee (Daviey, 16:04:12) ''LINK:'' https://blueprints.launchpad.net/~james-page/+specs?searchtext=servercloud-q&role=assignee (s3h, 16:04:57) ''LINK:'' http://people.canonical.com/~davewalker/delta.html (Daviey, 16:06:53) ''ACTION:'' zul talk to arosales and jamespage offline about SRU tracker (s3h, 16:07:05) *Quantal Development Specs currently under consideration are at https://blueprints.launchpad.net/~ubuntu-server/+specs?role=drafter. If a spec is missing, let Daviey know. Blueprints which $user is responsible for driving to Approved state can be found at https://blueprints.launchpad.net/~$user/+specs?searchtext=servercloud-q&role=assignee. Please set those which require review to Review state. Daviey urges now is the time for frantic work on merges. http://people.canonical.com/~davewalker/delta.html shows the delta with sid.(Continue reading)
, and I
recommend this approach. There were a couple of exceptions in
ubiquity, either where requiring straight-up binary data or where
dealing with text that's potentially in mixed encodings indicated by
field names.
* Three-arg raise is particularly awful for compatibility, because the
Python 2 form is an uncatchable SyntaxError in Python 3; you have to
use exec() to work around this. ubiquity only had one instance of
this, so I used six.reraise().
* pyflakes got upset with functions/methods defined two ways depending
on sys.version, so I had to add some exclusions.
* python-libxml2 hasn't been ported. If you're currently using this,
consider whether you can just use something in the standard library
instead, rather than the larger python(3)-lxml. I switched ubiquity
over to xml.etree.cElementTree, and aside from the expected
footprint-related virtues of using the stdlib, it actually ran faster
in our case.
* I had to port PyICU to get the test suite working. This had been
done upstream, but required packaging.
* Be careful with what 2to3 says about list/iterator/view-related
changes on dictionary methods and similar. Its conservative approach
is to add list() more or less everywhere, but if you're actually
using .items() etc. only as an iterator, you can leave it as-is.
Watch out for cases where you modify the dictionary while iterating
over it, though; in that case you'll indeed need list().
* I know others (including Barry) advocate 'from __future__ import
unicode_literals'. I found this a good approach in tests, but it
makes me nervous in library code since it could easily end up
changing your API. I'd say only attempt this if you have
exceptionally good test coverage.
Now, ubiquity's test suite isn't everything it might be, although I was
pleased to find that it got me most of the way. However, I still had to
attack some frontend/backend glue code, and the KDE frontend is
currently untested (any volunteers?). PyKDE4 had been ported upstream,
but required packaging; thanks to Philip Muškovac for reviewing and
uploading my patch there. There were then a few other things to fix,
including calling sip.setapi("QVariant", 1) until I figure out what's
going on with the new QVariant API, and joyously discovering that most
bits of PyQt4 finally return ordinary Unicode strings in Python 3 rather
than messing about with QString objects.
But, finally, it all works at least in my tests. I expect there'll be a
bit of shakedown time, but once things have settled I anticipate the
main benefit being that we stop having failures only in languages that
use non-ASCII characters, which has been a headache for us in the past.
I also expect to be able to drop the compatibility code once everything
is working and it's clear that we're past the point of no return in
using only Python 3 on the desktop image.
I definitely felt a tipping point here: once I'd ported a couple of
packages, my approach to subsequent ones has been to go through all the
changes I made for previous ports and duplicate each of them, which
really speeds things up. Plus, of course, each library helps another
batch of packages. Now that both GTK (via PyGI) and PyKDE are usable,
it should be possible to attack quite a few multiple-frontend programs
in Ubuntu; so please do!
--
Colin Watson [cjwatson <at> ubuntu.com]
RSS Feed