
Steve Langasek has been contributing to Debian for more than a decade. He was a release manager for sarge and etch, and like many former release managers, he s still involved in the Debian release team although as a release wizard (i.e. more of an advisory role than a day-to-day contributor). Oh, and he did the same with Ubuntu: on the picture on the left, he just announced the release of Ubuntu 10.04 from his Debian-branded laptop.

He has also been maintaining PAM in Debian for as long as can I remember and does a great job at that. He s very knowledgeable and fully deserves his place within the Debian Technical Committee. I m glad he still has the time to participate on several important Debian mailing lists because his contributions are always very useful.
I m sure you ll notice this just by reading his answers below. My questions are in bold, the rest is by Steve.
Who are you?
I m 32 years old, have been running Linux since my first year in college
back in 96, and have been a Debian developer now for ten years. Along
the way I ve been involved in maintaining a variety of server packages,
worked on the Alpha port for a while, did a stint as a release manager
for a couple of years, and serve on the technical committee.
This year I m also celebrating my ten year anniversary with my lovely
wife Patty, who many know as an erstwhile front-desk volunteer at
DebConf. God only knows why she puts up with my late-night hacking!
These days in my day job I m a manager on the Ubuntu Platform team at
Canonical, working to help make Ubuntu a daughter distribution that the
Debian community can be proud of.
What s your biggest achievement within Debian or Ubuntu?
There s no doubt that my biggest achievement in Debian has been overseeing
the release of two Debian releases as release manager.
On the other hand, the scope of a release is so huge, and it represents
the output of so many developers working together, that it would be
arrogant to claim the release itself as an achievement of my own. Also,
sarge and etch have long since been rotated off of the mirrors so no one
cares about them anymore.

For a more personal and lasting
contribution in the distro itself, I m very proud of writing
pam-auth-update. It s a small piece of code, but one that Debian was
missing for a long time it s made a big difference to PAM module
integration in packages!
What are your plans for Debian Wheezy?
My top priority for this cycle is to see multiarch through. We re still
not far enough along in Debian for most developers to see any
difference and once we are, the first thing people are going to see
is a fair bit of breakage when we start breaking a lot of assumptions
about paths that have been hard-coded upstream. But I m still excited
by the progress that is being made here. We should be able to ship
wheezy without any ia32-libs package. We might even be able to get rid
of all the biarch library packages, including those used by the
toolchain itself. 54 packages in testing build-depend on gcc-multilib
right now, in order to build 32-bit code to ship in the amd64 package; a
bunch of those should go away with absolutely no reduction in
functionality, saving us a bit of space in the archive and saving the
maintainers a lot of complexity in their packages, while at the same
time giving us much better support for cross-compilation than we ve ever
had before.
It s a tall order, certainly, but the pieces are falling into place one by one.
My second priority is to get a policy in Debian around packages
integrating upstart jobs. It would of course benefit Ubuntu to have
many packages back in sync with Debian, but if all we wanted was to sync
with Debian, we could mostly just make debhelper ignore upstart jobs in
Debian, prefer them in Ubuntu, and call it good. I m interested in
making sure Debian also gets the benefits of being able to use
upstart, because as Linux has become increasingly asynchronous (doing
more in parallel at start up), the traditional sysvinit has not been
able to keep up. There are all kinds of bugs now related to network
startup, for instance, that we don t have a good answer for in a sysvinit
model but that we can fix with an event-based system.
Upstart has been around for a while now, but we ve been slow to
integrate it into Debian because it only works on Linux. It would be a
shame if right after the first Debian GNU/kFreeBSD technology preview,
packages all stopped working on kFreeBSD because they started to assume
the availability of upstart! Unfortunately, having been so cautious we now
have systemd on the scene, which not only doesn t support non-Linux but seems
to be in the process of trying to gobble up other, non-Linux-specific
components of the desktop stack. So I have to wonder what the future holds
for the free desktop on non-Linux kernels.
If you could spend all your time on Debian, what would you work on?
Well, based on my previous experiences when I
did spend all my time on
Debian, I think the answer here is QA / release work.

Otherwise, I don t
know. My hands are full enough now with multiarch that it s hard for me to
see what the Next Thing would be.
You re a member of the technical committee. In the
interview of Bdale Garbee, I have argued that it s not working well. What s your point of view on this topic?
Well, I feel a constant low level guilt about my own poor level of
activity in the TC; but that doesn t translate into a belief that the
system is broken. This is, after all, the decision making body of last
resort for technical disputes in Debian, and as such it should really be
used sparingly. And if a reputation for glacial deliberation means more
developers work out their disputes on their own rather than asking the TC
to step in, I think that s actually a healthy thing!
I do still wish we were more effective at resolving those issues that do
come our way, but there s no silver bullet for this. Though the funny thing
is, I ve noticed that the majority of issues that get referred to the TC
nowadays never even need us to make a decision; a short conversation with
the disputants is often enough to get them to come to an agreement.
What s the biggest problem of Debian?
By and large, I think Debian is still doing a great job at what it s
best at delivering a rock-solid distribution that users can rely on.
If I would highlight one problem in Debian, though, it would be that I
think we re becoming less innovative as time goes on. Part of that comes
from being such a large project that we re bound to be more conservative
as an institution; but even though the three pet Debian projects of mine
that I mentioned above are fairly innovative (multiarch, pam-auth-update,
upstart), each of these has landed first in Ubuntu rather than in
Debian. Always with a clear intent of pushing back up into Debian, of
course, but it just wasn t possible to do this work within Debian for
the first cut without much longer delays.
I worry that if Debian is no longer the place to try new things, that
we re going to miss out on attracting contributions from the folks who
are inspired to make Free Software better and not simply to make it
stable.
I m not sure how to address this, though. Maybe improved conversations
with derivatives such as (but not limited to) Ubuntu, about what crack
of the day is being tried where and how that can be integrated into
Debian once it s proven to work? I don t think that team-based
maintenance or low-threshold NMUs do anything to address this, though,
as the kinds of innovation that matter most are ones that require
discussion and consensus-finding not just routing around inactive
maintainers.
Do you have wishes for Debian Wheezy?
Well, I d like to see the armhf port get on its feet and become an
official port. Over the lifetime of the arm and armel ports, the state
of the art on ARM has changed quite a bit; it would be great to see
Debian taking advantage of this richer platform, to let people make
better use of their hardware via Debian.
As a former release manager, you re now a release wizard . I guess you have seen it on debian-devel, there are proposals to not freeze testing and to use another distribution starting as a snapshot of testing to finalize the new stable release. According to your experience, what needs to happen to make this possible?
Frankly, I ve stayed out of that discussion because I don t think what s
being asked for is possible. I think proponents of a freezeless
release have seriously underestimated the amount of work required on the
part of the release team to wrangle testing into a releasable product,
and that anything that makes propagation of fixes into the pending
release more time consuming will make Debian worse on the whole, not
better.
If people really want to avoid long freezes for the Debian release, the
best way they can help this happen is by making Debian more releasable
on an ongoing basis, by helping to hold our packages to our shared
standards for quality (i.e., by fixing RC bugs!). The biggest factor in
long freezes for Debian is the slow rate at which we bring the RC bug
count down during the freeze. Back in the sarge, etch days we used to
have really great bug squashing parties that would get people together
on weekends to hack through RC bugs by the dozens. I don t see that
happening as much anymore. I d really like us to get back to that, but
my few attempts at this so far since retiring as release manager have led me to think
I m really terrible at organizing parties of any kind.

On the other side, as seen at
http://bugs.debian.org/release-critical/, the RC bug count for testing
at the beginning of the release cycle keeps getting higher and higher.
I d love to know why that is so we can address it. I know we ve gotten
better at detecting some classes of RC bugs; that s part of it, but I
don t think it explains the whole trend.
Is there someone in Debian that you admire for their contributions?
Wow, what kind of arrogant jerk would I be if I didn t admire anyone in
Debian for their contributions? Debian is and always has been an
amazing community of top-notch developers; there are certainly too many
I admire to list them all here. Joey Hess certainly makes the list, for
his longstanding example of code speaking louder than words and for his
ability to get to the heart of common problems and come up with elegant
solutions. So does Russ Allbery, who by all accounts had his ability to
feel anger in response to email burned out of him at a young age in a
flame-related accident on Usenet.

The list goes on, but here I think
I have to follow Joey s example and cut the words short.
Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on
Identi.ca,
Twitter and
Facebook.
3 comments Liked this article? Click here. My blog is Flattr-enabled.