LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsDebian Project Leader election draws nearStefano Zacchiroli has served as Debian Project Leader (DPL) since April 2010, and has announced that he will not stand for another term. The election for his replacement will take place between March 31 and April 13. In the meantime, much of the campaigning is taking place on the debian-vote mailing list, where project members have posed questions to the candidates and gotten detailed responses in reply (not to mention, in some cases, lengthy discussion threads).When his term ends in April, Zacchiroli will have been DPL for three years, the longest stretch since project founder Ian Murdock's in Debian's early days, so the 2013 election is attracting more attention than in previous years. Candidates and platformsThe candidates are Gergely Nagy, Moray Allan, and Lucas Nussbaum. Each one volunteered (or, technically speaking, nominated himself) during the official nomination period in early March. The three have written their own "platform" documents, which are hosted at the 2013 election page. Each sets out the general reasons the candidate is running for DPL and the issues he hopes to address if elected. Nagy ran for DPL in 2012 as well, and his platform begins by revisiting the issues he raised back then, and how the intervening 12 months have shifted his positions. In 2012, his platform focused on recruiting new project members, and on building a more "passionate" community in addition to one that excels technically. His current platform expands on that idea, with more specifics—such as increasing the opportunities for face-to-face events, publicly highlighting the contributions of experienced Debian Developers, and recruiting more non-packaging contributors. Allan's platform focuses on the role of the DPL itself; he says that the DPL can help overcome the occasional conflicts between the many loosely-organized teams in the project. The DPL can mediate in conflicts, he says, but can also encourage more turnover in team leadership (and rotating members between teams), and can facilitate more organized discussions between teams. He would provide guidelines for more transparency and openness in communication within the project, and build more active relationships with outsiders for the teams that handle press, publicity, and corporate relations. He, too, advocates bringing a Debian presence to more local events and user group meetings, and actively recruiting new contributors. He also proposes forming fundraising teams to seek out donations for the project's various expenses. Nussbaum begins his platform statement expressing concern that the core project is losing momentum; "very cool things" happen in the ecosystem, but outside Debian itself—which, if not careful, can lapse into contenting itself as a "package supermarket." He advocates reinforcing Debian in central position in the free software ecosystem, by fostering innovative products within the project itself (such as rolling releases and live images), reducing barriers to contribution, and improving communication with upstream projects. He also says he plans to continue Zacchiroli's DPL helpers initiative, but with the long term hope of evolving it into a driving team of Debian Developers who act as decision makers, with the DPL as chairperson. Position papers like the aforementioned platforms are nice, but in the modern world a campaign thrives on debate in order to get the candidates to explain themselves. In lieu of a stage, podium, and moderator, the DPL candidates have at least been offered the chance to respond to questions from project members via the debian-vote mailing list. Several of the questions were directed to all three candidates and asked for elaboration on specific points raised in one of more of the platforms. For instance, Timo Juhani Lindfors asked how each candidate would attract new people to the project, and Paul Tagliamonte asked how the candidates would represent Debian to the outside world. In both instances, the replies were on the safe side, although the question of attracting new participants did shift to address the "graying" of the project, and how to attract more youthful participants. The big freezeWhere the discussion got more interesting, however, were the threads in which a list member posed an original question. Many of these dealt with the daily grind of keeping Debian development moving forward, or on the long-term organization of the project. For example, Lars Wirzenius observed that Debian has been in feature freeze for eight months, which is significantly longer than most distributions, and asked what the candidates would do to fix the long and painful release process and other development process problems. Nussbaum responded with a number of ideas, including prioritizing the QA process and improving support tools like bug trackers. But he also suggested "more exploration of gradual freezes," perhaps in stages:
I understand that it's important to freeze early packages that affect
the installer, and maybe also the base system. But freezing all packages with
the hope that it will force people to fix RC bugs in other people's packages
does not work: many people just stop working on Debian during the freeze.
This was discussed a bit already, but I'm not sure that we really were
throughout in the discussion. As a DPL, I will reopen that discussion at a
good time (after the release, and not just after the release).
Allan said he does not think the DPL should "try to impose policies on teams like the Release Team," but provided a few ideas, including removing buggy packages much earlier in the freeze, and more actively flagging buggy packages. He also said that some form of Constantly Usable Testing (CUT) would be helpful, since many desktop users would prefer it:
This would solve the freeze problem for that group of users -- though
I worry that it might further reduce the number of people putting
energy into our current type of releases. Equally, I wouldn't expect
the existing Release Team to make CUT happen, both because of lack of
time, but also because they're likely to be self-selected as people
who like the current style of release.
Allan also observed that many packages ship with bugs that are tagged -ignore, which sometimes means the packages in question are unusable for some users even if they do not adversely affect others. One solution might be to declare separate release dates for different uses cases; "we could badge the new release as ready for the desktop before we close it off as final and suggest that people upgrade their servers." Nagy responded that the fundamental problem is that fixing bugs is not perceived as rewarding, and it is considerably harder in many cases because upstream developers cannot be relied on for assistance. The answer, he said, "is to make upstreams, downstreams and everyone else involved realise that if we work together, we'll release faster."
I feel the collaboration between Debian and downstreams is far from
perfect, and that is usually a fault of both sides. Tiny little speckles
of dust in the machinery some of these problems are, but if enough dust
accumulates, the machinery will suffer.
We need to figure out if - and how - we could work together more closely, to reduce the workload on all sides, as that also reduces the annoyance we may have with one another. Decisions, decisions, decisionsZacchiroli raised two questions about how Debian tackles distribution-wide changes. First, he asked how they would improve on the inertia that in the past has made Debian slow at planning and deploying large changes. Subsequently, he asked the candidates how they, as DPL, would approach the tricky problem of making such potentially far-reaching decisions—for example, which init system this distribution should use. As he put it,
Some of the longest -devel thread in recent years have been about
Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc.
Despite folklore, I don't think those threads have been (entirely)
trollish, they all hint at a concrete problem:
How do we make an inherently archive-wide technical decision when multiple, possibly equally valid solutions do exist? No candidate advocated drastic changes (perhaps predictably; after all, it is hard to imagine any candidate answering with a response that does not make technical merit the top priority). But the replies do provide insight into the candidates' viewpoints on how the project should be managed—for instance, how big of a role the Technical Committee (TC) should play in making calls between competing proposals. Nagy replied that big technical decisions like the init system should be addressed at in-person events like DebConf, where the stakeholders can sit down and discuss the topic:
We need to establish the key requirements (which in this case, will be
a tough cookie to crack too), and see what compromises the stakeholders
are willing to make. The primary role of the DPL in this case would be
organisation and mediation, to make sure that those involved understand
that compromises will have to be made, or we'll be stuck with sysvinit
forever, which is likely not what most of them would want.
Nussbaum said that the decision should be left up to developers and key package maintainers, with the TC only stepping in on rare occasions. The DPL can be helpful in facilitating discussions, he said, which usually result in a thorough review of the possible solutions—while the final decision will usually involve compromise:
Often, there's the possibility to limit the impact of the decision, e.g.
by providing a default, but also supporting alternatives. When that's
possible, that's something that should be explored. It's a good thing
for the current alternatives, but also to help future alternatives
later.
Allan also said the DPL was not usually the best fit for making large-scale decisions, but instead could "encourage people to improve UIs, agree on best practice, and write better documents." He also cited his platform document, which suggests "that we might make distribution-wide changes quicker by more vocally authorising NMUs [Non-Maintainer Uploads] to help with changeovers." To the pollsWhile the role of project leadership is an important one, and while Debian has long grappled with how to improve and streamline its release process, there are naturally plenty of other issues about which Debian project members have questions. Money came up several times; Raphael Hertzog inquired whether Debian should spend its money on anything other than hardware and travel reimbursement; various responses included code camps and underwriting individual developers. Martin Zobel-Helas asked specifically whether or not the project's planned hardware expenditures were justifiable. Here again, the candidates do not stake out drastically different positions, but their responses to the specific questions illuminate some distinctions, like how they connect budgeting for expenses to fundraising (both in terms of ongoing contributions and short-term campaigns). The discussion on the debian-vote list is likely to continue until the voting period begins on March 31. The candidates are also posting material on their individual blogs (as are other Debian project members). There is a generally amiable tone to the campaign, as one would expect from a mature project staffed by volunteers. But the campaign itself is interesting to watch for a few reasons. For one, it has been three years since the last change of DPL; when Zacchiroli was running for re-election the campaigns largely turned into a referendum on his continued presence in the role (which, although certainly a valid question for the voters, is different than the question of setting new priorities for the project). But another interesting facet of the election is the fact that it provides the public with an insight into the inner workings of the project management. Debian is not unique among Linux distributions for electing its leadership by a completely democratic process, but it is in the minority. The Fedora Project Leader is a full-time employee of Red Hat (who also appoints four of the remaining nine Fedora Board members); openSUSE is governed by a community-elected board but with a chairperson appointed by SUSE; Ubuntu sponsor Mark Shuttleworth serves as project leader until he decides to step down, though the distribution has an elected community council as well. In contrast, Debian's open leadership-selection process provides a window into the topics of debate that every distribution leadership team faces—at one time or another, anyway. And Debian is different in that the DPL is its sole elected leadership position. Selecting four or five board members all at once allows the voting public to make compromises and put together a broad ticket; the DPL works alone. Then again, the DPL "works alone" solely in the sense that the project's bylaws set out, and the DPL's role differs significantly from the decision-making powers often wielded in other projects. In reality, the DPL does not dictate policy, but works to coordinate and communicate between developers and to represent the project to external projects and communities. Thus, in other ways, the DPL remains just one active participant in the Debian community, which has always stayed both active and vocal—and seems likely to continue doing so, regardless of who takes home the most votes.
Brief items Distribution quote of the week
Or, to put it another way, for Fedora 18, Fedora got a lot of
publicity for being late to release. The project was able to say,
quite reasonably, "The installer has undergone a major rewrite, and we
want to make sure all the problems are ironed out first." For Fedora
19 do we want to say, "We're late to release because we wanted to put
an 'ö' in the release name."?
-- Ian Malone
Distribution News Debian GNU/Linux bits from the DPL: February 2013 (and a half)Stefano Zacchiroli presents his penultimate bits as Debian Project Leader. Topics covered include DPL elections, delegations, DPL helpers, Debian assets, and more.
Backports integrated in the main archiveThe Debian Project has announced that the backports service for Debian 7.0 "Wheezy" will be part of the main archive. "Backports are packages mostly from the testing distribution (and in few cases from unstable too, e.g. security updates) recompiled in a stable environment so that they will run without new libraries (whenever it is possible) on the Debian stable distribution. While as for now this service was provided on a separated archive, starting with wheezy-backports the packages will be accessible from the regular pool."
Release update: the hundred bug chargeThe Debian release managers have a report on the progress of Debian 7.0 "Wheezy". The freeze is in its final stages. There are still some RC bugs that need to be squashed and the release notes are not ready yet, but overall the release is getting ever closer.
openSUSE Geeko Pumping Iron Session - openSUSE ARM HackathonThe openSUSE ARM team will be holding a hackathon April 8-12, 2013 at the SUSE offices in Nuremberg, Germany. People may participate online.
Newsletters and articles of interest Distribution newsletters
Klumpp: TangluMatthias Klumpp introduces Tanglu, a Debian-testing derivative still in early development. "Tanglu is designed to be able to solve the issue that Debian is frozen for a long time and Debian Developers can’t make new upstream versions available for testing easily. During a Debian freeze, DDs can upload their software to the current Tanglu development version and later start the new Debian cycle with already tested packages from Tanglu. The delta between Tanglu and Debian should be kept as minimal as possible. However, Tanglu is not meant as experimental distribution for Debian, so please upload experimental stuff to Experimental. Only packages good enough for a release should go into Tanglu."
Ubuntu to halve support length for non-LTS releases (The H)The H reports that support for Ubuntu's non-LTS releases will be shortened to nine months. "In a meeting of the Ubuntu Technical Board last night, the technical leadership of Canonical's Linux distribution decided to halve the support time for non-LTS releases to nine months. At the same time, the developers want to make it easier for users of the distribution to get up-to-date packages on a regular basis without the need to perform explicit upgrades of the whole distribution. Attending the meeting, Matt Zimmerman, Colin Watson and Stéphane Graber unanimously agreed on these points and also clearly voted against moving Ubuntu into a rolling release model. The changes will be implemented in the maintenance schedule starting with the release of Ubuntu 13.04 ("Raring Ringtail") on 25 April."
Page editor: Rebecca Sobol |
|||||||||||||