Multirelease effort: Moving to Python 3

[Toshio Kuratomi]

Hey, I'm forwarding this on from Barry Warsaw.  He's a contributor to
Debian and Ubuntu and has been very active in managing porting to python3
both within those communities and as an upstream python committer.  So he's
experienced in a lot of the work that we're going to be embarking upon to
move this forward.

-Toshio

Begin forwarded message:


Date: Mon, 22 Jul 2013 18:34:01 -0400
From: Barry Warsaw <barry at python.org>
To: devel at lists.fedoraproject.org
Cc: Python-devel at lists.fedoraproject.org
Subject: Re: Multirelease effort: Moving to Python 3
Organization: Damn Crazy Followers of the Horn
X-Newsreader: Claws Mail 3.8.1 (GTK+ 2.24.20; x86_64-pc-linux-gnu)

On Jul 22, 2013, at 03:31 PM, Miloslav Trmač wrote:

>IMHO this is precisely the kind of integration where a distribution is
>perfectly justified to carry local patches, even against explicit
>wishes of upstream if necessary (though cooperating with upstream and
>finding a way to integrate the patch upstream is much better).  We
>shouldn't block the transition just because a one or two upstreams
>refuse to port (or, more likely, a dozen or two upstreams do not exist
>any more).

In my own experience, most upstreams are very grateful for contributions which
improve/add the Python 3 support.  They will often work with you to craft your
changes so they are more easily accepted upstream.  I've encountered only one
or two cases of "unfriendly" upstreams who either can't or won't cooperate
with a distro's contributions here.  Most know that we're past the Python 3
tipping point; you either support it or risk being irrelevant.

As for abandoned upstreams, it's almost always better to find a replacement
and port those packages which depend on the abandonware.  A good example is
oauth, which hasn't been updated since 2009.  oauthlib is a better library
*anyway* and the fact that it is Python 3 compatible is definitely a plus.
The APIs are different, but not so much so that porting isn't possible.

Tougher are things like pygtk -> gobject introspection, but a lot of that work
has been done, so helping those projects along benefits the entire Python
ecosystem.  You also have to consider big frameworks, but some of the really
key ones like Twisted and Django are already well on their way to Python 3.

One tip for carrying distro-specific patches.  You sometimes have to do this
because while upstream may accept your changes, they can often be slower to do
releases than what you need.  Try to at least get upstream to commit the
changes to their VCS so you know the patches are blessed, and that once the
upstream releases, you can drop your deltas.  Carrying a VCS derived patch is
way better than carrying one that upstream disagrees with.  (Sometimes
upstream even knows better, as was the case with my first dbus Python 3 port
:).

You should really view distro-specific patches as temporary if absolutely
required, and avoid them if at all possible.

Cheers,
-Barry






----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130723/dbe0f2e8/attachment.sig>