Package: tech-ctte Severity: normal Hello Technical Committee, we'd like you to decide about how the Python interpreter packages should be maintained in Debian.
The problems that we have with the current situation can mostly be described by having a look at the way the Python 2.6 transition is being handled. 1. The Python maintainer delayed the upload of version 2.6 for 14 months since the first upstream release, without giving a valid technical reason for doing so. At the same time, the same maintainer uploaded said Python 2.6 package quickly to Ubuntu, which released twice with this version as default before it was uploaded to unstable. 2. When finally uploaded, the python2.6 package contained an unplanned transition to a new location for installed modules. This solution was not discussed at all with other maintainers and led to major changes having to be rushed into all packaging tools, and hundreds of packages left to be fixed. 3. The Python maintainer didn't provide any kind of impact analysis of this transition, leaving all the burden on other maintainers (mostly the Python modules team) and didn't try to set up dialogue with the team, which was left to file bugs and do NMUs so that packages could build cleanly with these changes. At the same time, the same maintainer provided a very thorough analysis of the upcoming changes in GCC 4.5, collaborating with other developers to test them on a large scale, and thus proving he has all technical and communication skills to do this. 4. The Python maintainer delayed adding python2.6 to the supported versions, asking for python2.4 to be removed first. It is a good thing to remove python2.4 of course, but it could have been done later (or earlier), without delaying the former important step. 5. The Python maintainer didn't provide an environment where maintainers could test their packages with python2.6 as default in experimental, which is something that was asked since he announced the 2.6 transition. Again, the Python modules team was left the burden of setting up test environments, filing bugs, helping other maintainers to fix their packages, preparing and sponsoring NMUs, etc. When asked about this situation, he replied indirectly (using another developer as a proxy) that he is working on adding additional features unrelated to the transition before this happens. 6. The Python maintainer has still virtually zero communication with the Debian Python modules and Python applications teams, and there seems to have been no significant progress in this. This situation is not new. Similar problems occurred for previous Python transitions, starting as early as python2.2 and getting worse over the time, despite the increasing amount of work put in Python-related tools and of people involved in Python packaging. A common pattern is that he often blocks important transitions to force some controversial, unrelated technical changes to be implemented before these transitions happen. Given all these points, we think that the current Python maintainer has no real interest in maintaining Python in Debian, and no interest in working in an open fashion with other people committed in this area. Therefore, we.d like to move the maintainership of pythonX.Y* (interpreters and related packages) and python-defaults (due to its specific role in the Python environment) packages to a team of people that already showed their involvement in Python in Debian, their ability to work in a team, and their will to bring a constant attention to Python in Debian; among them we propose ourselves: - Luca Falavigna <dktrkr...@debian.org> - Josselin Mouette <j...@debian.org> - Sandro Tosi <mo...@debian.org> - Bernd Zeimetz <b...@debian.org> - anyone else willing to help, including of course the current maintainer, provided the above points are met. Thanks to the amount of work the Python modules team has done for this transition, Python 2.6 can now become the default version in unstable (of course after the approval of the Release Team) with minimal breakage, so that time can be the smoother one to hand the package over to a team. Thanks for your attention, Luca, Josselin, Sandro, Bernd PS: attached you can find the same text along with our signature of it. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash
Hello Technical Committee, we'd like you to decide about how the Python interpreter packages should be maintained in Debian. The problems that we have with the current situation can mostly be described by having a look at the way the Python 2.6 transition is being handled. 1. The Python maintainer delayed the upload of version 2.6 for 14 months since the first upstream release, without giving a valid technical reason for doing so. At the same time, the same maintainer uploaded said Python 2.6 package quickly to Ubuntu, which released twice with this version as default before it was uploaded to unstable. 2. When finally uploaded, the python2.6 package contained an unplanned transition to a new location for installed modules. This solution was not discussed at all with other maintainers and led to major changes having to be rushed into all packaging tools, and hundreds of packages left to be fixed. 3. The Python maintainer didn't provide any kind of impact analysis of this transition, leaving all the burden on other maintainers (mostly the Python modules team) and didn't try to set up dialogue with the team, which was left to file bugs and do NMUs so that packages could build cleanly with these changes. At the same time, the same maintainer provided a very thorough analysis of the upcoming changes in GCC 4.5, collaborating with other developers to test them on a large scale, and thus proving he has all technical and communication skills to do this. 4. The Python maintainer delayed adding python2.6 to the supported versions, asking for python2.4 to be removed first. It is a good thing to remove python2.4 of course, but it could have been done later (or earlier), without delaying the former important step. 5. The Python maintainer didn't provide an environment where maintainers could test their packages with python2.6 as default in experimental, which is something that was asked since he announced the 2.6 transition. Again, the Python modules team was left the burden of setting up test environments, filing bugs, helping other maintainers to fix their packages, preparing and sponsoring NMUs, etc. When asked about this situation, he replied indirectly (using another developer as a proxy) that he is working on adding additional features unrelated to the transition before this happens. 6. The Python maintainer has still virtually zero communication with the Debian Python modules and Python applications teams, and there seems to have been no significant progress in this. This situation is not new. Similar problems occurred for previous Python transitions, starting as early as python2.2 and getting worse over the time, despite the increasing amount of work put in Python-related tools and of people involved in Python packaging. A common pattern is that he often blocks important transitions to force some controversial, unrelated technical changes to be implemented before these transitions happen. Given all these points, we think that the current Python maintainer has no real interest in maintaining Python in Debian, and no interest in working in an open fashion with other people committed in this area. Therefore, we.d like to move the maintainership of pythonX.Y* (interpreters and related packages) and python-defaults (due to its specific role in the Python environment) packages to a team of people that already showed their involvement in Python in Debian, their ability to work in a team, and their will to bring a constant attention to Python in Debian; among them we propose ourselves: - Luca Falavigna <dktrkr...@debian.org> - Josselin Mouette <j...@debian.org> - Sandro Tosi <mo...@debian.org> - Bernd Zeimetz <b...@debian.org> - anyone else willing to help, including of course the current maintainer, provided the above points are met. Thanks to the amount of work the Python modules team has done for this transition, Python 2.6 can now become the default version in unstable (of course after the approval of the Release Team) with minimal breakage, so that time can be the smoother one to hand the package over to a team. Thanks for your attention.
python_tech-ctte.asc_bzed
Description: PGP signature
python_tech-ctte.asc_dktrkranz
Description: PGP signature
python_tech-ctte.asc_joss
Description: PGP signature
python_tech-ctte.asc_morph
Description: PGP signature
