On May 10, 2010, at 01:23 PM, Piotr Ożarowski wrote: >Why I think derivatives should not add new versions? >* because it's mostly chasing numbers - I'm pretty sure there are not > more than 10 packages that require Python >= 2.6 and are not easy to > port to 2.5 in Ubuntu 10.04, >* because when you have to convert hundreds of packages, without > checking them carefully (most packages in Ubuntu don't have maintainer > assigned to them) you end up with "fixes" like: > - disabling tests, > - breaking perfectly valid XS-Python-Version or debian/pyversions, > - hardcoding "-I /usr/include/python2.6" in debian/rules (yes, 2.5 was > still in supported when I saw it) > or no fixes at all (>100 packages that FTBFS, ignoring broken > XS-Python-Version or debian/pyversions, packages that build > correctly, pass all tests... and do not work[1]), >* because new version often means changes in helper tools (cdbs, > debhelper, python-central, python-support) and you're risking the > situation where we will not like your implementation and will rewrite > them in incompatible way (and that will mean you will have to rewrite > them again), >* because we're supporting upgrades from oldstable only (do you know how > many packages in Ubuntu are suffering from missing/too many > Conflicts/Replaces/Provides: pythonX.Y-foo?) (this argument is > actually semi related, as you cannot do much if we will drop support for > one of versions and you still support it in LTS) >* because of crazy ideas like implementing "include-symlinks" in > python-support or using virtualenv in Debian packages as workarounds ;-P These are all really good reasons; thank you for outlining them! Let's assume that when adding a new version requires changes such as you've described above, we have discussed them here and have reached consensus on the approach. It may be true that we disagree on the specific implementations, but let's further assume that our intentions are all good (i.e. that we *want* to work together and forge a common path). The question then becomes, if Ubuntu makes the decision to leap onto a new Python version before Debian does, and we take on the burden of achieving consensus and doing much of the work, how can we ensure that Debian gains the benefit of it in a way that works with your development process? What I mean is, let's say we have to change something in a helper tool. We want that change to happen at least also in Debian, if not first in Debian, but because of our different release cycles, where would we put it? Ubuntu already sync's with Debian, but does it make sense to for example, put changes that are required in Ubuntu first, into Debian experimental? At least that way, Debian will gain the benefit of it when they catch up. If experimental isn't the right place for that, what is? Or is there no place that we can sync changes from Ubuntu to Debian for things like this? -Barry
Attachment:
signature.asc
Description: PGP signature