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 <ba...@python.org> To: devel@lists.fedoraproject.org Cc: python-de...@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 -----
pgp6lUt0Y_oOU.pgp
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
