LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsWho should maintain Python for Debian?A two-year old Debian technical committee "bug" highlights some interesting aspects of Debian governance. The problem comes down to technical and personal disagreements about Python maintenance for the distribution. That bug has remained open since March 2010, though it may soon be resolved—based on the history, even saying that may be premature. That history raises a larger question, however: how should a project handle a situation where developers and maintainers of cooperating packages can't seem to get along—or even communicate? March 2010More than two years ago, Sandro Tosi noted some problems in the maintenance of the Python interpreter package. In that report, he pointed out that Python 2.6 for Debian was delayed for 14 months after it was available upstream, though the maintainer (Matthias Klose) had released two Python 2.6 packages for Ubuntu in the interim. In addition, once a Debian version was uploaded to unstable, it contained changes to the location of installed modules that broke various packaging tools and packages (mostly Python modules). That transition came with no warning, Tosi said, which is symptomatic of another problem: Klose is not communicating with the rest of the Debian Python community. Because of those problems, Tosi asked the committee to make a decision about who should maintain the interpreter packages going forward. Tosi suggested that a new maintenance team be appointed for the Python interpreter and python-defaults packages. That message to the committee was signed by Tosi and three others (Luca Falavigna, Josselin Mouette, and Bernd Zeimetz) all of whom were proposed as the new maintainers. Others "willing to help, including of course the current maintainer" were also to be included. The discussion continued for several weeks, committee member Bdale Garbee did some investigation into the problems and concluded that a better Debian Python policy and plan was needed before any kind of decision could be made, while others discussed ways to add co-maintainers. The problems clearly go back further than the bug report, perhaps as far as a DebConf 6 Python packaging meeting that evidently went awry—probably even further back than that. Beyond the technical complaints, one of the major problems that is mentioned frequently by the (self) proposed new maintainers group is a lack of communication from Klose. Coordination with the module and Python application maintainers has been essentially non-existent, they said. Certainly the bug report itself is one example of that; in a long thread over two years, there is not one message from Klose. In addition, a look at the debian-python mailing list shows only a handful of messages from him in that time frame. Klose maintains some "key packages (bash, binutils, gcc, java, python, and several others)", according to Tosi. That may leave him stretched a little thin. It may also be that he prefers other forms of communication (IRC is mentioned frequently). There are also hints in the thread that Klose may no longer be talking to those in the "new maintainer" camp due to longstanding "bad blood" stemming from both technical and personality conflicts. Whatever the reasons, there is some kind of fragmentation going on in the Debian Python community. Part of it seems to be caused by Ubuntu-Debian conflicts, but the bulk of it stems from Klose's maintainership, which, at least in the eyes of some, is characterized by a "my way or the highway" attitude. The technical committee was fairly obviously leery of stepping into the middle of that mess and just making a decision. The committee members discussing it seem to have reached consensus that there are problems in the community, but none of the proposed solutions look like they will clearly make things better. November 2010The initial discussion petered out in July 2010. In November 2010, Debian Project Leader (DPL) Stefano Zacchiroli noted that he was frequently asked about the issue. Things had gotten better, he said, and discussions on transition strategies were taking place on the mailing list, which was a step in the right direction. He noted that while Klose was not always participating in those discussions, "it is also clear that he follows them and seems to agree with where they are going". But, that said, he stills sees a problem:
Nevertheless, the big issue is undeniably still open: maintenance of the
main Python interpreter packages is still up to a single maintainer,
with no mutual trust and/or communication between him and (most of) the
rest of the Debian Python community.
Additionally, as DPL, I'm worried by seeing packages as important as the Python interpreters maintained by a single person. Even if all other surrounding issues were not there, that would be a bus-factor problem worth fixing by itself. (I concede there are other similar situations in the archive, but this is no excuse; they are just other problems to be solved.) He concluded by saying that he didn't envy the committee for the decision it has to make, but was clearly encouraging a resolution to the problem. After there was no response for nearly two months, another ping from Zacchiroli in December was mostly met with silence. March 2011That led Zacchiroli to make another proposal in March 2011. While he makes it clear that he is not trying to step on the committee's toes, he proposed that it defer the decision to him. The proposal looks like something of a last gasp attempt to help the committee make a decision of some kind. That elicited some response, though no one really felt that it was right to delegate the decision to the DPL. Ian Jackson expressed disappointment in the lack of a decision and suggested that the packages in question be orphaned, while requesting that interested teams apply to become the maintainers. Steve Langasek was opposed to that, and suggested that the committee re-affirm Klose as maintainer with encouragement to take on co-maintainers. On the other hand, Russ Allbery thought that finding a team to maintain the interpreter packages, one that included Klose, would be the ideal solution. But, like the others, he was not really in favor of delegating to the DPL. And that's pretty much where this iteration of the conversation dropped. March 2012Tosi pinged the bug again in November, then in March 2012 ("2-years-old ping"). The latter is what prompted the most recent re-kindling of the discussion. The participants in this round seem resigned to taking a vote, with some discussion on what the options should be. Zacchiroli volunteered to try to firm up the possible alternative teams for Python maintenance and, to that end, posted a message to debian-python asking for interested parties to speak up. Several people spoke up to volunteer, along with some who were opposed to replacing Klose. That led to a message from Zacchiroli summarizing the discussion and outlining the teams that were available to be placed on the tech committee's ballot. He followed that up with a bit of a poke on April 27: "I hope this could help and that the tech-ctte have now all the input needed to quickly come to a conclusion on this issue, one way or another." A bit of dialogue on the makeup of the three possible "teams" ensued, but the discussion pretty much ended there. In his DPL report, Zacchiroli mentioned his recent involvement and concluded: "I hope the tech-ctte now have all the information needed to come to a decision". May 2012 (and beyond?)It is a rather strange situation overall. It seems clear that the committee is not completely comfortable affirming Klose as the sole maintainer, and he has not commented as to whether he would be willing to co-maintain the interpreter packages with others. But an "overthrow" of Klose is not very palatable either. By waiting, presumably hoping that things would correct themselves on their own, the committee has put itself into an awkward position. Had it re-affirmed Klose two years ago (or one year ago, or ...) the problem may in fact have solved itself. Perhaps the unhappy petitioners would have "taken their marbles and gone home", but, by now, one would guess any package maintainership holes would have been filled. If it gives Klose a vote of confidence now, after a two year consideration phase, there are likely to be questions about why it was left to linger so long. Meanwhile, deposing Klose now will raise more or less the same questions. As is typical in a Debian ballot, however, all of the proposals so far also include the "further discussion" option, so the committee could conceivably kick the can further down the road. It's clear that Zacchiroli and others would rather not see that. The powers of the DPL are famously limited by the Debian Constitution, but Zacchiroli has done everything in his power to try to get some kind of closure on the issue. It is up to the technical committee to pull together a final ballot and put it to a vote; it seems likely that almost any decision (other than "further discussion" perhaps) would be better than none at this point. Or maybe the conversation will just die until the "three-year ping" comes along.
Brief items Distribution quotes of the week
You'll say: but the code is free! Yes, it is. Which is about as valuable
as... Let's see - how many distribution-specific package managers have been
ported to others?
-- Jos Poortvliet
My pet hypothetical solution of the day is that mailing lists might raise
the quality of the debates by limiting the number of messages written by
each person per day in each thread. This might, I think, induce people to
write with more thought and put more effort into making each message count.
-- Lars Wirzenius
btw, is the concept of numbers smaller than zero but not negative known/used
anywhere outside of debian/dpkg?
-- Holger Levsen
Tizen has drawn a lot of crap from their complete silence and secret
cathedral building behaviour up to 1.0 release. But I can say that if I was
in their shoes, having to launch a handset device .. and handset stack. I
would probably end up doing the same things as they had. In a world where
you will see your semi-ugly alpha release screenshots laughed at in news
articles about your 1.0 launch, when you have a perfectly working and very
shiny final release that nobody seems to bother to even check out, it's
hard to argue for transparent development from day zero.
-- Carsten Munk
Distribution News Debian GNU/Linux (overlapping) bits from the DPL: April 2012Debian Project Leader Stefano Zacchiroli has a few bits from April that spans the end of his previous term and the beginning of his current term of office. The bits start off with a call for DPL helpers. Other topics include Debian's proposed diversity statement, revenue sharing with DuckDuckGo, the conflict on Python maintenance, multimedia packaging, hardware replacement, and more.
Fedora Appointment to the Fedora Board, and Elections ReminderGarrett Holmstrom has been appointed to the Fedora Board. "In this election cycle, three Board seats are open for election, and two Board appointee seats are open; the first appointee, Garrett, is being appointed prior to nominations opening, and the second will be appointed after elections are completed." Nominations for open seats on the advisory board, FESCo (Fedora Engineering and Steering Committee), and FAmSCo (Fedora Ambassadors Steering Committee) close on May 15.
The Future of Fedora release namesFedora members were recently polled on whether Fedora releases should have code names. The consensus is that many people like having release names, but the method for choosing the names should be improved. The board is seeking volunteers to help come up with a new method.
Mandriva Linux "Dear Community – II" from MandrivaThe Mandriva blog has another letter to the community with very little in the way of actual useful information. "The Mandriva Linux project has the right to be given a space in which it may expand and the contributors and afficionados a place where they can express their talents. We are precisely working on this right now and during the next two weeks. We will announce the direction we intend to give to the project during the third week of May. It makes no doubt that it’ll be difficult to satisfy each an every expectation and wish, as they’re many of them and some are not compatible with the other, but we’ll try to achieve what can be useful and most promising for the community and, with it, the Mandriva Linux project."
Newsletters and articles of interest Distribution newsletters
Dell announces prototype development laptop with Ubuntu (The H)Dell has announced Project Sputnik, which is aimed at producing a laptop for developing mobile and cloud applications. The H takes a look. "The laptop is pre-installed with an image based on Ubuntu 12.04 LTS that has been optimised for Dell's XPS13 Ultrabook. The project has already solved problems with the brightness control and the WiFi hotkey and is now working on issues with the touchpad which currently only works as a single touch pointing device with no scrolling. The install also includes several development packages such as version control systems and automatic deployment tools. Plans for the future include the automatic fetching of setup profiles for other software packages from GitHub."
Page editor: Rebecca Sobol |
|||||||||||||