[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#573745: marked as done (Please decide on Python interpreter packages maintainership)

Your message dated Fri, 5 Oct 2012 12:03:32 -0700
with message-id <20121005190332.GE8318@rzlab.ucr.edu>
and subject line Re: Bug#573745: Call for votes on Python Maintainer Question
has caused the Debian Bug report #573745,
regarding Please decide on Python interpreter packages maintainership
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
573745: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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 <dktrkranz@debian.org>
 - Josselin Mouette <joss@debian.org>
 - Sandro Tosi <morph@debian.org>
 - Bernd Zeimetz <bzed@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 <dktrkranz@debian.org>
 - Josselin Mouette <joss@debian.org>
 - Sandro Tosi <morph@debian.org>
 - Bernd Zeimetz <bzed@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.

Attachment: python_tech-ctte.asc_bzed
Description: PGP signature

Attachment: python_tech-ctte.asc_dktrkranz
Description: PGP signature

Attachment: python_tech-ctte.asc_joss
Description: PGP signature

Attachment: python_tech-ctte.asc_morph
Description: PGP signature


--- End Message ---
--- Begin Message --- 
The outcome was no longer in doubt some time ago; the committee
therefore resolves:

The technical committee was asked in #573745 to consider replacing the
current maintainer of python (Matthias Klose.) Multiple issues were
presented at the time, including a lack of communication from the
python maintainer, delays in uploads of new versions of python to
unstable/experimental, and a lack of coordination with packaging
helpers such as python-support, and python-central.

1. The communication between the python maintainer and other
individuals affected by python packaging has not been ideal. These
breakdowns appear to be rooted in an unfortunate feedback loop, of
which all parties involved share some blame.

  a) On multiple occasions, inflammatory comments regarding the
  employment and/or motives of individuals involved in python have
  been made.

  b) The target(s) of these inflammatory comments then decline to
  respond to any messages from the offending parties, and also reduce
  public communication to other parties lest further hurtful and
  demotivating comments ensue.

  c) The lack of response is taken as further confirmation of
  motives/bias, and decreases the threshold for additional terse or
  inflammatory comments. This reinforces b, completing the loop.

Neither the inflammatory comments, nor the lack of response are
acceptable outcomes.

2. No mediation was attempted by a party respected by the involved
parties until the pattern was well established and very difficult to
overcome. In the future, everyone would be better served if similar
issues were resolved in a nascent stage.

3. To resolve this issue, the committee has two options. It can either
replace the maintainer, or it can decide not to replace the
maintainer. Either decision will appear to validate one problematic
behavior or the other.

4. All relevant and interested parties have been canvassed, via the
-python list, to find what the possible teams of maintainers are for
the python interpreter packages. See
https://lists.debian.org/msgid-search/20120403083658.GB30420@upsilon.cc
and the ensuing thread.

Therefore, 

5. The committee expresses its disappointment in the communication
problems which have lead to this issue, and strongly suggests that all
involved parties be as awesome to each other as possible. In the advent
of communication failures or problems, we request that any involved
party contact a third party (such as a member of the technical
committee) to mediate.

6. The committee requests that all major changes in the python
interpreter packages which will affect other packages in Debian be
announced on the appropriate mailing lists before they take effect so
they can be planned for and/or unplanned problems discussed.

7. The committee declines to change the maintainer of the python
interpreter packages in Debian.

8. The committee requests that Matthias Klose consider adding
additional co-maintainers to the python interpreter package.





Don Armstrong

-- 
America was far better suited to be the World's Movie Star. The
world's tequila-addled pro-league bowler. The world's acerbic bi-polar
stand-up comedian. Anything but a somber and tedious nation of
socially responsible centurions.
 -- Bruce Sterling, _Distraction_ p122

http://www.donarmstrong.com              http://rzlab.ucr.edu

--- End Message ---
Reply to: