The 2005 Debian Project Leader election
The Debian Project Leader (DPL) election is fast approaching. The nomination period ended on February 28, and the campaigning period runs through March 21. The field of candidates is much broader than in recent years, with six serious candidates vying for the role of Debian Project Leader. Current DPL Martin Michlmayr is not running for re-election.
The candidates, and their platforms, for 2005 are Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, and Branden Robinson.
We sent a list of questions to each candidate to find out where they stand on issues facing Debian in 2005. The first question we posed to the candidates was how they would help to ensure that Sarge would be released this year, and if too much emphasis was placed on a new stable release.
In his platform, Walther endorsed the idea of a six-month release cycle,
borrowed from the OpenBSD project, saying it could "turn Debian into
a monster powerhouse of software goodness
". In his response, he
added that he was unsure of the limits of the DPL's authority, but would do
"everything in my power to get Sarge out the door immediately, as-is,
and formalize the OpenBSD/Ubuntu/Xouvert 6-month release cycle.
"
Towns responded that there were a variety of reasons that Sarge had been
delayed, and that "the release team currently have a handle on
them
". He also said that releasing Sarge is "the highest
priority for the project at this point, and the highest priority of the DPL
is to do everything possible to ensure that the release team and those
working on resolving the remaining issues have the support and resources
they need to do their work quickly and effectively.
"
Lees pointed out that the DPL "is not a position with direct control
over Debian's actions
" and that the DPL "is there to provide a
single point of contact with the outside world and to ensure the relevant
groups within Debian coordinate effectively
". He also said that he
is confident that the Sarge release would go out this year without
intervention from the DPL, but "would of course try to ensure that
the relevant technical teams have the resources they need to avoid any
further delays.
"
As for the importance of stable releases, Lees said that the stable
releases are necessary to provide "a static fork to provide security
fixes against and a known minimum point from which package maintainers must
ensure smooth upgrades
". The ideal release point, according to Lees,
would be "around the 1.5-2.5 year point, so shorter than the Sarge
release cycle - but not by much.
"
Garrett noted that Sarge is close enough to release that "anything
the DPL does is more likely to slow things down than speed them up.
"
A more interesting question is probably how we can prevent Sarge from happening again. A large part of the problem is that many people have lost faith in us ever making timely releases, which ends up costing us a lot - without the feeling that you're working towards a release, there's far less incentive to make sure that your code is in good condition and help track down bugs in other packages. I want to deal with this problem by making people believe that we can actually make releases when we say we will, and I think the first step towards that will be to make sure that we have a list of concrete goals for our next release the moment we've finished with Sarge.
He also said that slow releases not only cost Debian users, but development effort as well.
Robinson told LWN that he would work closely with the Release Management
team to find out what they need and "try to get those needs
satisfied, whether they involve hardware for build daemons, additional
personnel for the security or debian-installer teams, or simply general
encouragement (some would say whip-cracking) to get the release-critical
bug count down.
"
He also said that Debian is compared "unfairly and unfavorably to the
bleeding-edge nature of some distributions
" and could "greatly
mitigate that criticism by establishing a more predictable and regular
release cycle.
".
Finally, Schuldei said that Sarge should be in "deep freeze
already
" by the time the next DPL takes office on April 17. Schuldei
also said that regular releases "are important for Debian and are one
of my priorities.
"
The next question we posed to the candidates is whether Ubuntu had hurt Debian by drawing away development effort, how Debian should work with projects derived from Debian and if Debian was "infrastructure" for other projects.
Schuldei responded that Ubuntu "cherry-picked from Debian's most
active developers.
"
Those Ubuntu developers who used to work on Debian infrastructure were missed painfully, indeed. I hope that "Small Teams" as described in my platform can help by building lots of small multiplying knowledge pools which would make Debian resilient against loss of single individuals and enable it to grow able successors very quickly.
Schuldei told LWN that Debian "should more actively incorporate the
good things that it sees other distributions
" do and that if Debian
"managed the 'taking' as well as the 'giving' [to other projects]
there would be little limit to its potential.
"
Robinson says that Canonical
Ltd. (the company that sponsors Ubuntu) is a "mixed
blessing.
"
At the same time, Canonical's interests are not identical to Debian's. If Canonical is to operate anything like a conventional business that realizes revenue, it cannot help but pursue paths to do so. The Debian Project doesn't have that pressure on it. Inevitably in such an environment, at least some Debian developers who work for a commercial interest are going to experience tension between what's good for Debian and what's good for their employer, even if that divergence is perceived as merely short-term. In the short term, Debian needs to release sarge. We cannot count on Canonical, Linspire, Progeny, Xandros, Hewlett-Packard, or any of Debian's other benefactors to solve our problems for us -- they will not supply the magical second step between "collect underpants" and "RELEASE!", to spin an old joke.
He also said that Debian has to be "frank about it
" and accept
that some developers may be drawn away from Debian.
Garrett pointed out that Ubuntu "has taken some effort away from
Debian, but it's also contributed a lot back.
"
One of the fundamental reasons for free software is the right to produce derived works, and I think that making it as easy as possible for others to produce derived distributions is the best way for Debian to support that. The number of distributions based on Debian is large enough that I think we class as infrastructure, but don't think that's incompatible with making releases.
Providing employment for Debian developers is "a good thing
"
according to Lees, though he notes that "some inevitable divergence
between Ubuntu and Debian as Ubuntu strives to differentiate
itself.
"
What I'm really excited about from Ubuntu is some of the tools they're working on, like bug trackers and version control tools. These tools are being developed specifically for the unique needs of distributors, rather than authors, and it will be very interesting to see what they become.
Towns said that the only way Ubuntu draws developers away from Debian
"is by providing a better environment for hacking -- whether that be
by paying for the work, or being more fun, or being more satisfying, or all
of the above.
"
I think Debian works quite well both as a distribution of its own, and as infrastructure for other distributions; I hope it will improve as both.
According to Walther, projects like Ubuntu or Knoppix help Debian rather
than hurt it. "Because of our licensing, we can always fold things
back in from other projects that work out well.
"
We also asked candidates if they had any idea why so many people were running this year, as opposed to past years that saw only a few candidates.
Walther quipped, "because the incumbent decided not to run for
re-election.
"
Schuldei told LWN "some of the candidates clearly believe that Debian
is in need of their special knowledge or ability. I myself believe that my
vision for Debian and my experience in implementing change in social groups
will help the Debian Project to reach new heights and strength.
"
Robinson said that "people are getting a better idea of what they
want out of a Project Leader.
"
Garrett said that he can't speak for the other candidates, but "I'm
standing because I think Debian has problems that need fixing, and I think
being DPL is the best way that I can help fix them. Perhaps our problems
are more obvious this year than in the past?
" Lees told LWN that he
has no idea why so many people are running for DPL, and that he's running
"at the insistence of several other Debian developers, probably in
response to some of the more radical factions that are gaining influence
within Debian
". Towns said that there have been "a lot of
fairly controversial questions raised or decided...and in the midst of all
this the next release of our operating system has continued slipping. It
seems plausible to me that the range of candidates represent the range of
different views within the project of how to approach these issues.
"
Another topic that comes up frequently when discussing delays for Sarge is
dropping architectures. We asked the candidates if they thought Debian
should drop any of its architectures in order to release on a more timely
basis. There was not a great deal of enthusiasm for this idea among DPL
candidates. Walther is against the idea of dropping architectures
altogether. "I see no need to drop any architecture, but I do see it
as a good thing to release each architecture separately. This prevents the
lowest common denominator from retarding the distribution as a
whole.
"
Towns said, simply, "
Garrett told LWN that dropping architectures would not speed up the
release, and would "
If we get to the point where an architecture can't pull its weight, then
we'll drop it. We're not there yet.
Robinson said that the idea that dropping an architecture would benefit the
release cycle "
Finally, we asked the candidates what the biggest challenge facing the DPL
would be. Schuldei told LWN that scalability was the biggest problem facing
Debian.
The changes in the leadership and small team infrastructure as well as
nurturing of good working climate will address this effectively and will
allow Debian a new growth cycle.
Garrett sees communication as the largest hurdle for Debian:
Lees told LWN that Debian "
Towns said that the biggest single issue was "
Walther also told LWN that the release cycle is the largest problem for the
project.
Debian Developers may begin voting for DPL on March 21, through April
11. The voting procedure is described in section A of the Debian
Constitution. We'd like to thank each of the candidates for responding
to our questions, and wish them good luck in the election.
That's a decision for the release and archive
teams to make.
" Lees said that there was "no correlation
between the number of architectures and any delay in release
", as
far as he could see. Schuldei said, "
yes, that's one possible
option.
"
undoubtedly reduce the quality of our
distribution. There are whole classes of bugs that only show up when you
port to a wide range of platforms.
"
seems to meander between a vague notion and an article
of faith.
" He also said that he has yet to see a proposal that
explains how it would benefit the release cycle, and that he needs
"more convincing...to support such a dramatic step. For some
architectures, Debian is the only modern option for a GNU/Linux
installation. It'd be a shame to give that in exchange for an unproven
benefit.
"
basically works
" and said it was
difficult to sort out a minor issue to highlight as a problem. He also
touched on communication as a problem, and said VoIP would be an
"interesting way to improve the quality of communication...since
email seems to bring out the worst in people. I would hope that improving
the nature of the communication would make it easier to address other
issues that arise within Debian.
"
getting Sarge out the
door, but that's primarily an issue for the release team to handle
".
Robinson didn't respond directly to the question of the biggest challenge
for Debian, but also pointed out in his responses that "the collective
psyche of the project gets antsy when a release process has dragged on for
too long.
"
Index entries for this article GuestArticles Brockmeier, Joe
Posted Mar 10, 2005 15:58 UTC (Thu)
by heinlein (guest, #1029)
[Link] (1 responses)
Oh, and could someone tell Zonker that www.dissociatedpress.net is spewing SQL errors...
Posted Mar 11, 2005 4:09 UTC (Fri)
by jzb (editor, #7867)
[Link]
Posted Mar 10, 2005 17:59 UTC (Thu)
by dwheeler (guest, #1216)
[Link] (4 responses)
One reason people flock to Ubuntu is because they're doing more rapid releases. I think Red Hat has the basic idea right: two distribution lines, one released more rapidly (to increase functionality and speed bug fixing), then use that to create something that is released much more slowly.
I'd say there needs to be an intermediate step between "stable" and "testing" -- something that's released on a 6-month schedule that receives some distribution-wide testing, but not the insane delay of "stable".
Posted Mar 12, 2005 18:59 UTC (Sat)
by Zomb (guest, #23391)
[Link] (1 responses)
Posted Mar 15, 2005 22:12 UTC (Tue)
by piman (guest, #8957)
[Link]
Posted Mar 16, 2005 11:09 UTC (Wed)
by jstAusr (guest, #27224)
[Link] (1 responses)
Posted Mar 16, 2005 18:22 UTC (Wed)
by piman (guest, #8957)
[Link]
Unless you want to run recent hardware. If you're lucky you can get enough installed to upgrade right away; if you're unlucky you end up with an unsupported hard drive or network adapter.
> After the next Debian release, the processes that will be in place, will cause all your concerns to basically go away.
We have all heard this before (testing was going to do it, for example). I think the new process will help, but it is not a magic bullet, and there definitely need to be more changes.
Debian doesn't need 6 month releases, to be sure. That's ridiculously fast for servers. But like Joey Hess said recently, at this rate, Debian is going to manage two releases in ten years. That's unacceptable for everyone.
Nice article. I maintain a couple Debian boxes, but I'm not heavily involved in the project. The interviews were nice little overviews of some issues the organizers are facing.The 2005 Debian Project Leader election
Zonker knows, man, Zonker knows... Dead hard drive. Bad mojo. It'll be down another day or so. The 2005 Debian Project Leader election
I think Walther is basically right; there needs to be a speedier release cycle for Debian. The current process is completely broken for desktops and even for many servers. Anything that takes 3 years to release is completely broken.
Walther is basically right
walters does not provide anything specific, he brings only hot vapor and the old "should be 6months" term stolen from Ubuntu/BSDs (but not easily adaptable here).Walther is basically right
There is no clear solution but a promising way is to build a leader council (which is beeing brought up together right now, but without walters, thanks god).
Not Walters, but Walther. Colin Walters is a well-respected developer (and not running for DPL). I suspect Jonathan Walther may be the first DD to rank below "None of the above" on the election results.Walther is basically right
To say that "Anything that takes 3 years to release is completely broken." when referring to the Debian distribution, would be similar (not exactly the same as) to saying your writings are completely wrong. Your comments show a lack of understanding of the subject. Anyone connected to the internet has several options if they prefer not to use the stable release including; testing, unstable, backports, and partial upgrades. For those not connected to the internet, things wouldn't be as good but they could still get a set of CDs made from testing, and its not like stable isn't functional. After the next Debian release, the processes that will be in place, will cause all your concerns to basically go away. Debian doesn't need to have six month releases, they need to be a great distribution and have more people understand the goals of the project.Walther is basically right
> its not like stable isn't functional.Walther is basically right