Distributions

Debian Python followup

By Jake Edge
October 24, 2012

Back in May, we reported on a longstanding Debian technical committee "bug" that proposed replacing the Debian Python maintainer. The bug has existed since March 2010, and the problem of dysfunctional communication among the maintainers of various Python packages goes back further than that. It looked like things might be coming to a head in May, but the problem was finally resolved—or at least the technical committee rendered a judgment—on October 5.

It is not clear what precipitated the restart of the technical committee vote process, though a thread on hijacking packages in debian-devel at the same time may have been a partial trigger. In any case, Don Armstrong drafted a resolution for consideration on September 27. A few comments were made, which were then addressed by Armstrong, who called for a vote on October 4. The vote was quickly resolved in favor of not replacing Matthias Klose, the Debian Python maintainer.

While the vote was lopsided, it was hardly a ringing endorsement for Klose or his communication style. The other two options (besides the ever-present "further discussion") were to turn over the Python package to two different teams led by new maintainers: Sandro Tosi, who filed the original bug, or Jakub Wilk, who volunteered back in April. The choice for leaving Klose as the maintainer includes an additional clause that suggests a change:

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

The resolution also contained a bit of a recap of the problems, at least from the perspective of the committee. The communication difficulties reached a point some time ago that Klose has essentially stopped posting to the mailing list (and, for that matter, never posted any kind of response or clarification in the bug). Those problems stem from a feedback loop spelled out in the resolution. Essentially, flames posted about the motives of various participants led them to withdraw from communicating, which resulted in more flames (and, eventually, the resolution). The resolution notes: "Neither the inflammatory comments, nor the lack of response are acceptable outcomes."

It has been clear over the two and a half years this has gone on that the committee members are rather disappointed that they are faced with the issue. It is not just that they have a make a hard decision that "will appear to validate one problematic behavior or the other", but also that the parties involved couldn't resolve it on their own.

It is a bit unclear what the result of the decision will be. Wilk is still active on the debian-python mailing list, while Tosi hasn't posted in more than five months. Neither may be a long-term indicator of their plans regarding Python in Debian. After initially being resistant to a forcible change of maintainer, Wilk changed his mind on August 10, which is how his name ended up on the resolution ballot. That may also have helped spur a final tech committee vote on the issue.

But, moving forward, the committee did make a request to address one of the bigger problems that was cited when the bug was first filed. Because of the lack of communication, changes to Python packaging that affected other related packages were not being announced. In a clause that would have been present no matter how the vote went, the resolution covers that problem:

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.

It is certainly a sticky situation when maintainers of related packages cannot seem to get along. Debian is famously maintainer-oriented, giving those maintainers wide latitude in how they handle "their" packages. That was likely a significant factor in the decision-making process. But, even with the vote, things may really not be resolved and the committee may need to get involved again. One hopes not, but the resolution doesn't necessarily really change anything.

Comments (1 posted)

Brief items

Distribution quotes of the week

Ryan Hill wrote:

> I'm assuming that since we're now having dozen-post threads about
> whether or not to have periods in our descriptions that all the hard
> stuff has been solved?

Perhaps in planning QA, for now, but certainly not in executing it. Documentation is lacking, too, and then some people still wouldn't read it anyway, and with more EAPI changes we keep adding more ways to screw it up, so please stand still while we reinvent the wheels on your desk chair.

-- Jeroen Roovers

Taking over unmaintained packages should not be hard. We need people to do it. We need people to do it more than they do today. We need to make it easy.

-- Sune Vuorela

Focusing on outcomes is what I'm all about - forget about EAPIs - focus on what it is that we really want, and make those things that really matter.

-- Rich Freeman

Start with an idea, discuss it, come up with a plan, find resources for that plan, and then implement. Sometimes things happen the other way around, but only when we happen to be lucky, and it often has consequences like extra ongoing work with no support. So, just talk is an important place to start.

-- Matthew Miller

Comments (none posted)

Ubuntu 12.10 (Quantal Quetzal) released

Ubuntu 12.10 "Quantal Quetzal" has been released. Desktop, Server, Cloud, and Core images are available for download now; the official variants (Kubuntu, Xubuntu, Edubuntu, Lubuntu, and Ubuntu Studio) are expected to follow later today. Among the changes in this edition, of course, is support for UEFI secure boot.

Full Story (comments: 3)

Distribution News

Debian GNU/Linux

Bits from Debian Pure Blends

Debian Pure Blends are distributions that take packages from Debian's main repository to create a smaller and more focused distribution, such as Debian Science or Debian Med. These bits cover scientific citations, prospective packages in VCS, a proposal to move Blends code from SVN to Git, and a brief look at some existing Blends.