From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SNkpd-0002Nb-5F for garchives@archives.gentoo.org; Fri, 27 Apr 2012 13:03:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67405E0652; Fri, 27 Apr 2012 13:03:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E1437E0652 for ; Fri, 27 Apr 2012 13:03:24 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id 305921B4006 for ; Fri, 27 Apr 2012 13:03:24 +0000 (UTC) Received: by werm13 with SMTP id m13so494112wer.40 for ; Fri, 27 Apr 2012 06:03:21 -0700 (PDT) Received: by 10.180.78.164 with SMTP id c4mr5874364wix.10.1335531801788; Fri, 27 Apr 2012 06:03:21 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.18.208 with HTTP; Fri, 27 Apr 2012 06:03:01 -0700 (PDT) In-Reply-To: <4F935B10.1030206@gentoo.org> References: <4F935B10.1030206@gentoo.org> From: Dirkjan Ochtman Date: Fri, 27 Apr 2012 15:03:01 +0200 Message-ID: Subject: Re: [gentoo-python] Testing dev-lang/python version bumps To: Mike Gilbert Cc: gentoo-python@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 3978b6f3-5900-4d6d-8adb-98b13f3d9876 X-Archives-Hash: ab66446ed55d37a9297e7b27d8c951e2 Thanks for doing this! Sorry it took so long to review them... we should try to think of some easier review mechanism than putting up a tarball you have to unpack. On Sun, Apr 22, 2012 at 03:12, Mike Gilbert wrote: > If we can get some people testing these that would be great. I would > like to add them to the tree sometime in the next week. I wonder, do you have a rationale for including each patch? IMO, Arfrever has a tendency to diverge a bit further from upstream than I like, and I note that you've taken in some patches and don't seem to have gone in upstream. These are the differences between my 2.7.3 patchset and your 2.7.3-0: 1. Added 08_all_regenerate_platform-specific_modules.patch, which doesn't seem to be upstream yet. 2. Added back 22_all_turkish_locale.patch, which AFAIK isn't upstream, nor associated with an open upstream bug? 3. Added 61_all_process_data.patch, for which the goal seems somewhat unclear. You also removed the mention of the upstream bug from 04_all_libdir.patch, probably just by mistake? As for 3.2.3, I'm also -1 on including 23_all_h2py_encoding.patch after reading http://bugs.python.org/issue13032. Including 26_all_gdbm-1.9.patch in 3.1.5 is probably a good idea. For 3.1.5's 09_all_sys.platform_linux2.patch, I'd prefer if we just reuse ${FILESDIR}/linux2.patch, unless that doesn't apply for some reason. Now, we can certainly discuss adding these patches on this list, but I think we should try to maintain some balance on the upside of having extra fixes in our ebuilds and the amount of maintenance we're willing to do on carrying those patches forward (e.g. the distutils patch is a pretty big pain, and it seems like more of a feature than a bug). I don't think we should throw everything out on revbumps or bugfix releases, but for new releases such as 3.3 I would personally like to do only the bare minimum of patching. Cheers, Dirkjan