On Oct 20, 2012, at 01:45 PM, Matthias Klose wrote: >> 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, > >If you need fixing a package for a new python version, how often do you break >a previous version? Will upstreams even accept this kind of patches?
I suspect that any upstream that already supports Python 3.2 would gladly accept patches to also support 3.3 (if any are even necessary). I'm sure *dropping* 3.2 compatibility probably won't be acceptable for packages that already support it, but it might also be difficult to convince the ones that haven't moved to Python 3 yet to skip 3.2. Other distros (including Wheezy btw) will still have 3.2 as their likely default Python 3 for a while. >If you think that the reintroduction of u"" strings will help porting, I'll >backport this to 3.2 temporarily (provided that it doesn't end up in a >release). I don't think this will be necessary, but I also wouldn't recommend doing it. We definitely don't want to ship an official Python 3.2 with u-'' prefixes enabled, and I suspect the number of packages it will actually help is going to be pretty small. >Point 2) is (afaics) done. I do not want to rely on the 3.3 work being done >in a PPA only, this time is lost during the development cycle. It doesn't >expose 3.3 until it's the default, and things like the dbus-python/3.3 issue >mentioned earlier in the thread show that it's not always easy to get these >PPA configurations correct (and yes, we had some issues back with the 2.6/2.7 >tests in a PPA too at the end of the last year, which then came up as a >surprise in the archive). > >So lets open with 3.3 as a supported version from the start, and drop 3.2 when >3.3 is made the default (or shortly after). Adding a new version doesn't >break the existing packages in the archive, issues are usually only exposed at >build time. I think it's a must to check for the common site/dist-packages >layout. If people do not want to address the pyqt "tooling" issues, these >should be at least documented in the bug tracker. > >6) is not really an option (but maybe it's expected from your position to >provide such a fallback ;) I just want to reiterate that my biggest concern is the potential for Python 3.3 support work to detract from the general Python 3 porting effort. As long as the former doesn't consume all our time, and we can still make progress on the latter (if not accomplish it for task:ubuntu-desktop), then I'm all for going ahead. If not, then I think we need a fallback position. ISTM that we really don't have a good idea of the effect of Python 3.3 will be, and we need to do rebuilds in order to find out. Whether this happens in a PPA, a local build or the primary archive, we still need to do it and gather the information. If we do it in the archive (i.e. start with 3.3 supported but not default) and we need a fallback, then I think that would be to peg the maximum Python 3 version for such packages at 3.2 so build failures against 3.3 won't break the package. But we can do this much later in the cycle if necessary (and of course, I hope it won't be). -Barry -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
