When should Python 3.3 become the default?

Steve Langasek steve.langasek at ubuntu.com
Fri Oct 19 19:41:55 UTC 2012


Hi Barry,

On Thu, Oct 18, 2012 at 05:04:35PM -0400, Barry Warsaw wrote:
> Continuing on discussions we've had at previous UDSes, and looking ahead to
> the probably schedule for Python 3.4, it is almost certain that we'll carry
> Python 3.3 as the default Python 3 for the next LTS (14.04).  Whether we'll
> also have Python 3.2 or 3.4 in 14.04 LTS is an open question we don't need to
> decide right now.

> Clearly we're going to enable Python 3.3 as a supported Python 3 version
> when the 'raring' archive opens up.  The question is whether 3.3 should be
> the default Python 3 as soon as the archive opens, or whether we should
> keep 3.2 as the default, enable 3.3, and watch for any fallout before
> making the switch later in the 13.04 cycle.

There seem to be a lot of big unknowns about how much work is needed, so I'm
not sure it helps for me to weigh in, but here's my two cents anyway.

Supporting multiple versions of python3 in our source package tooling is
obviously important over the long term.  However, supporting multiple
versions of python3 is never a goal per se for an Ubuntu release (or, for
that matter, a Debian release): it's something we do only when we need to,
in order to support applications that don't manage to all be ported to the
same python version at the same point in time.

The set of existing software in quantal that depends on python3.2 is still
comparatively small: less than 500 packages all told (source+binary).  I
haven't sorted through to see how many source packages this actually is, but
it's probably closer to 300 total.  (This compares to python2, which has
4705 source+binary revdeps in the archive.) Some fraction of these packages
will require additional porting to make them work with python3.3, but it's
not clear to me how much that work is.  Do we have some way to estimate?

If the python3.2->python3.3 porting work is small enough to do in one cycle,
I think it's beneficial for us to focus on this porting exclusively and
*not* worry about making packages work with both python3.2 and python3.3,
because that's incidental to our actual goals.  This is certainly the last
time we could consider making such a hard cut from one python3 version to
another, but I think we should consider it because:

 - It avoids us blocking on bugs in packages / tooling that prevent
   supporting multiple versions of python3 today.  We obviously need to fix
   those *eventually*, but it's not something that's going to be a priority
   in Debian right now due to the freeze, so if we don't have to deal with
   it right now we'll spare ourselves having to carry a delta.
 - As we identified at last UDS, there are advantages to porting directly to
   python3.3 when coming from python2.  Getting python3.2 entirely out of
   the picture should, over the slightly longer term, buy us back some
   effort when it comes to the python2->3 transition.
 - It sends a clear signal to upstreams that they should be targeting 3.3,
   not 3.2.  Yes, this may again hurt our python3 support in the short term
   because some software supports python2 + python3.2 upstream and not
   python3.3; but I think getting python2 off the CD for 13.04, only to have
   to ship both python3.2 and python3.3 instead, is not really a win for us.
 - Python 3.3 has multiarch support and 3.2 does not.  So keeping 3.2 around
   has implications for cross-bootstrapping of Ubuntu, which is also on the
   list of topics for UDS.

So here's my strawman proposal.

 1) Open raring with python3.2 as default, and only, supported python3
    version.
 2) Fix the issues that prevent dh_python3 being used for python3.3, ASAP.
 3) Stage rebuilding all of the python3 revdeps against python3.3 in a ppa.
    Identify all build failures.  Determine if these are tractable to sort
    out for raring.  If not, go to step 6.
 4) Iterate in the PPA (pushing the necessary support patches to Debian,
    upstream, or raring as we go) until enough of the set is buildable with
    python3.3 that uploading it is not going to be disruptive to other
    development.  Focus in particular on python3.3 compatibility in those
    packages which build-depend on python-all-dev.
 5) Upload to raring, switching to python3.3 in one go.
 6) If we determine that we can't make it all the way up the hill to
    3.3-only in time for raring release, back off: make python3.3 a
    supported version, but make 3.2 the default.

Please tell me if this sounds crazy.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121019/82e78183/attachment-0001.pgp>


More information about the ubuntu-devel mailing list