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
More 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
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.
The 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
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
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.
That 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.
Tosi 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.
Comments (5 posted)
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
Comments (none posted)
Debian 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.
Full Story (comments: none)
Garrett 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.
Full Story (comments: none)
Fedora 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.
Full Story (comments: none)
The 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.
Comments (10 posted)
Newsletters and articles of interest
Comments (none posted)
Dell has announced Project Sputnik, which is aimed at producing a laptop
for developing mobile and cloud applications. The H takes
. "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.
Comments (3 posted)
Page editor: Rebecca Sobol
Next page: Development>>