apt-get install debian-wizard

Insider infos, master your Debian/Ubuntu distribution

  • About
    • About this blog
    • About me
    • My free software history
  • Support my work
  • Get the newsletter
  • More stuff
    • Support Debian Contributors
    • Other sites
      • My company
      • French Blog about Free Software
      • Personal Website (French)
  • Mastering Debian
  • Contributing 101
  • Packaging Tutorials
You are here: Home / Archives for News / Debian News

People behind Debian: Steve Langasek, release wizard

May 6, 2011 by Raphaël Hertzog

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.

People behind Debian: Meike Reichle, member of Debian Women

April 21, 2011 by Raphaël Hertzog

Meike Reichle is a Debian developer since 2008 but has been involved for longer than that, in particular in Debian Women. She’s a great speaker and shared her experience in a Debconf talk.

She’s also part of the Debian publicity team and managed the live coverage of the last release on identi.ca. Enough introduction, learn more about her by reading the interview. My questions are in bold, the rest is by Meike.

Who are you?

My name is Meike Reichle, I am a studied information scientist and work as a project manager at Pengutronix, an embedded Linux company probably best known for their ARM kernel work. I live in Germany, more exactly in Lower Saxony, but I was originally born and raised in Swabia. Although I moved here ten years ago I still have a rather strong Swabian cultural identity. (Among other things I pride myself on having introduced a number of fellow DDs to the true promise that are real hand-made Spätzle ;-)) I am married to Alexander Reichle-Schmehl, we’ll have our third wedding anniversary this summer. Apart from Debian most of my spare time is used for all kinds of crafts and DIY activities. Making things with my hands always gives me a great sense of accomplishment.

My Free software history is summed up pretty quickly. Like most women of my age I wasn’t introduced to computers until well into my teens. I didn’t have a computer of my own until I started studying at the university in 2001. From there on things developed rather quickly: Working on the University’s Unix terminals got me hooked on *nixes, so I got me one of those “Linuxes” everyone talked about. I tried a couple of different distributions, ended up with Debian around 2004, started contributing in 2005, and finally became a full DD — what a nice coincidence! — exactly this day (Apr 18th) three years ago.

You’re part of Debian Women. How is the project going? I have the feeling that the number of women involved in Debian has not significantly increased.

The amount of women active within Debian is a tricky thing to judge. Here’s a quick example why:

When the DPL was elected in 2004 there were 911 Debian Developers eligible to vote, 4 of them were female. Shortly after, during DebConf4, debian-women was founded. When the current DPL was reelected last month, there were again 911 Debian Developers eligible to vote, but this time 13 of them were women.

You can look at these numbers and say “The number of female DDs has more than tripled, what a success!” Or you can pull out your calculator and it will tell you that in terms of ratio this puts us from a measly 0.4% to an only slightly less measly 1.4% ratio of female DDs. This still is — pardon my language — a bloody shame, but sadly also pretty close to the average ratio of women in Free Software.

So, while I do think that the debian-women project did already have a significant impact on the Debian project as a whole, I don’t think it has achieved its goals yet. Not for a long time.

There’s still a lot to be done but unfortunately the debian-women project has somewhat run out of steam at the moment. The seven years of its existence divide quite equally into the first half, which was very active and saw great results, and the second half, which was very slow and much more passive. In my impression debian-women is currently undergoing a rather bumpy generational change. On the one hand a lot of the original members, including myself, have reduced their involvement. Speaking for myself this is caused by shift of interests as much as general weariness. On the other hand there are only very few women following up. This development is also reflected quite harshly in DD numbers: If I don’t misjudge any first names (and I desperately hope I do!) for the last three years not a single woman has joined Debian as a developer! After the great start debian-women has had, this is a very painful thing to see!

That said, things don’t look all bad. There is a number of women maintaining packages without being DDs and there’s also at least one woman currently in NM, so there’s hope this standstill won’t last very much longer. But still, the fact remains that debian-women is suffering from a rather serious recruitment problem and I hope that this interview might actually help to spur some new or not yet active members into action. The aim of debian-women is far from achieved and now that its initial members are receding its time for new members to step up and take initiative.

What should Debian do to be more attractive to women ? I think the general atmosphere has improved, we’re less tolerant with rude behaviour, the usual tone on mailing lists has improved. Yet it doesn’t seem to be enough.

If there was a female DD for every time I answered that question…

First of all, I agree, Debian as a community has improved tremendously! Our general tone is much more friendly and cooperative and there is now a much better awareness of the impression we give to outsiders and newcomers.

Now on to the difficult part: The question what should be done to get more women into Free Software has been around almost as long as Free Software exists, and it has been answered very well by a lot of people: Twenty years ago Ellen Spertus wrote Why are There so Few Female Computer Scientists? and most of it still holds true. Almost ten years ago Val Henson (now Aurora) wrote HOWTO Encourage Women in Linux and that also is still pretty accurate. In 2006 Floss Pols undertook extensive research to find out why there were so few women in Open Source and Free Software and how that could be changed. They also came up with a very good set of recommendations. All of these texts highlight different aspects of that question and all of them have very good points.

I personally have, over the years, arrived at a rather sociological, not to say holistic point of view. In fact I answered the exact same question a few days ago, and the answer I gave then was this: “After ~10 years of women in tech advocacy I’d say the ultimate and final measure to get more women into Free Software is by finally achieving a truly equal society and at the same time dramatically improving child care support in almost any country.” I’ve come to the conclusion that what really holds women back in practice is not so much a lack of skill or interest but a simple lack of opportunity. For most of us Free Software is what we do in our spare time and that’s something that women, even today, have considerably less of than men. Even in couples where both partners work full-time it is still mostly the woman who does the majority of the housework and child care duties. In most cultures men have a perceived right to their leisure time that does not to the same degree exist for women.

That is one major reason, the other is instilled modesty, which has kind of become my personal arch-enemy by now. I’ve talked to so many girls and women at all sorts of events about why they won’t take up Computer Science studies or join a Free Software project and the answer I hear most often is that they do not consider themselves “good enough” in one or another aspect. Sometimes they will doubt their technical skills, sometimes their language skills, sometimes their stamina. Needless to say these girls and women were not any less qualified than the people already active in Free Software.

So, yes, in the short and medium term making Debian a more welcoming and friendly place is the way to go. As many others pointed out already this will not only benefit prospective contributors but the community as a whole: those new to it as well as those who’ve been in it for a long time. In the long term however what we need is empowerment! Women who are just as confident about their skills as men and are not discouraged by uncooperative environments. This is of course something that is culturally deep-rooted and can only happen in a very large time frame. So, for the moment the way to go in my view is accessibility: a cooperative atmosphere, a code of conduct, comprehensive documentation not only of technical aspects but also of structures and processes. The other thing we need to do is to have as many already active women as possible attend as many Linux/Debian/Free Software/Whatever events as possible. In my experience it happens quite often that other women see these women, feel very inspired by them, get to talk to them and then a few days later show up on some mailing list or IRC channel. From what I’ve seen personal contact still beats any other kind of “recruiting” measures.

You’re a Debian developer but you’re also married with a Debian developer (Alexander Reichle-Schmehl). Did you meet because of Debian? If not, who introduced Debian to the other one? 🙂

We did in fact meet because of Debian. More specifically during our booth shift at the Debian booth at LinuxTag 2005, where I did a talk on the debian-women project and Alex organised the DebianDay. After that our relationship developed pretty much along our Debian activities: After our initial meeting we talked a lot on #debian.de, when Alex went to DebConf5 and I didn’t we noticed that we kind of missed each other. The first gift he ever gave me was a Debconf5 shirt and a box Finnish chocolates (I still have one of them today. :)) Our first secret kiss was at ApacheCon 2005, where we were both staffing the Debian booth (kudos to abe for pretending not to notice). We then became an “official couple” at Berlinux 2005 where we were both staffing the Debian booth and giving talks on packaging and user motivation. Our first real relationship stress test was when we both joined the DebConf6 orga team. It was a stressful time, but we passed it with flying colours! About a year later we announced our engagement via planet.debian.org. Our wedding was a veritable MiniDebConf, one of the best gifts we got was a Debian cookbook including the favourite recipes of DDs from around the world.

By now we’ve both finished university and work full-time jobs, so we don’t do as many talks and attend as many Debian events as we used to. Instead we now mainly focus on press and publicity work, which is quite practical to work on as a pair. It’s actually rather funny that way, Alex and I get confused with each other quite often, since we have almost the same name, often pick up on each other’s E-Mail conversations and are most often quoted by our function rather than by name. Because of we have kind of merged into this virtual Debian Press Person in the perception of many of our contacts.

You also have another “hat”: Debian Press Officer. What is this about? What would you suggest to people who would like get involved in that domain?

Debian press work is mainly about providing an official and coordinated point of contact to anyone wanting information from or about Debian. The press team answers all sorts of inquiries (the most popular one is is of course always the next release date) and makes sure all important events and developments within Debian receive the attention and recognition they deserve. Debian is a diverse project where every sort of contributor is free to voice his or her opinion in any way. We don’t have NDAs or prescribed terminology. That’s one of the things I love about Debian but also something that makes us difficult to handle for conventional media. They want official statements, in generally understandable terms, at appointed times. That’s what the press team takes care of. Almost all of the press work is done in the publicity team, which coordinates using IRC, Mail and SVN. The publicity team also publishes the Debian Project News, which are very popular among our users and developers. Press work is also an area of work that offers lots of possibilities for non-technical contribution. http://wiki.debian.org/Teams/Publicity lists a number of possibilities for contribution and, like most Debian Teams, we’d be more than grateful to get some more helping hands and happy to introduce interested newcomers to our work.

What’s the biggest problem of Debian?

In my view: Overwork. Debian has thousands of contributors but still a lot of the main work rests on very few shoulders. We need more contributors, especially, but not only in the key teams. In order to get more people we need to do some marketing which is very hard for us, since we are very proud of our independence and have a strong focus on purely technical aspects rather than aiming for popularity. However, with the current amount of Open Source and Free Software projects to join we find ourselves not only in a contest on technical excellence but also a sort of popularity contest that is about perception rather than hard facts. This popularity contest is difficult for Debian and currently costs us quite a bunch of very capable people.

Do you have wishes for Debian Wheezy?

My answer to that is a non-technical one: I think Debian is currently very under-appreciated, we do a lot of great work and maybe even more importantly we do a lot of important work for Software Freedom, sometimes even at the cost of our above-mentioned popularity. I hope people will appreciate that more again in the future.

Is there someone in Debian that you admire for their contributions?

Over the years I have made a lot of friends within the Debian community, some have even become family. That makes it somewhat hard to single out individual people. I think what I admire most is continuous commitment. I am very impressed by those among us who have kept up a high level of commitment over many years and at the same time managed to bring that in line with a fulfilled personal/family life. That’s something that I hope I’ll also be able to achieve in the years to come.


Thank you to Meike for the time spent answering my questions. I hope you enjoyed reading her 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.

Status update of GNOME 3 in Debian experimental

April 18, 2011 by Raphaël Hertzog

Last week’s post generated a lot of interest so I will make a small update to keep you posted on the status of GNOME 3 in Debian experimental.

Experimental is not for everybody

But first let me reiterate this: GNOME 3 is in Debian experimental because it’s a work in progress. You should not install it if you can’t live with problems and glitches. Beware: once you upgraded to GNOME 3 it will be next to impossible to go back to GNOME 2.32 (you can try it, but it’s not officially supported by Debian). Even with the fallback mode, you won’t get the same experience than what you had with GNOME 2.32. Many applets are not yet ported to the newest gnome-panel API.

So do not upgrade to it if you’re not ready to deal with the consequences. It will come to Debian unstable and to Debian testing over time and it should be in a better shape at this point.

Good progress made

Most of the important modules have been updated to 3.0. You can see the progress here.

The exception is gdm, it still needs to be updated, the login screen looks quite ugly right now when using GNOME 3.

Frequently Asked Questions and Common Problems

Why do links always open in epiphany instead of iceweasel? You need to upgrade to the latest version on libglib2.0-0, gvfs and gnome-control-center in experimental. Then you can customize the default application used in the control center (under “System Information” > “Default applications”).

You might need to switch to iceweasel 4.0 in experimental to have iceweasel appear in the list of browsers. Or you can edit ~/.local/share/applications/mimeapps.list and put x-scheme-handler/http=iceweasel.desktop;epiphany.desktop; in the “Added Associations” section (replace the corresponding line if it already exists and lists epiphany only).

The theme looks ugly, and various icons are missing. Ensure that you have installed the latest version of gnome-themes-standard, gnome-icon-theme and gnome-icon-theme-symbolic.

The network icon in the Shell does not work. Ensure you have upgraded both network-manager-gnome and network-manager to the experimental version.

Some applications do not start at all. If an application loads GTK2 and GTK3, it exits immediately with a clear message on the standard error output (Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported.). It usually means that one of the library used by that application uses a different version of GTK+ than the application itself. You should report those problems to the Debian bug tracking system if you find any.

Some people also reported failures of all GTK+ applications while using the Oxygen themes. Switching to another theme should help. BTW, the default theme in GNOME 3 is called Adwaita.

Where are my icons on the desktop? They are gone, it’s by design. But you can reenable them with gsettings set org.gnome.desktop.background show-desktop-icons true and starting nautilus (if it’s not already running). (Thanks to bronte for the information)

Why do I see all applications twice in the shell? The package menu-xdg generates a desktop file from the Debian menu information, those are in a menu entry that is hidden by default in the old GNOME menu. Gnome Shell doesn’t respect those settings and displays all .desktop files. Remove menu-xdg and you will get a cleaner list of applications.

APT pinning file for the brave

Since last week, we got APT 0.8.14 in unstable and it supports pattern matching for package name in pinning files. So I can give you a shorter and more complete pinning file thanks to this:

Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release experimental
Pin-Priority: 500

Package: *
Pin: release experimental
Pin-Priority: 150

Putting the file above in /etc/apt/preferences.d/gnome and having experimental enabled in /etc/apt/sources.list should be enough to enable “apt-get dist-upgrade” to upgrade to GNOME 3 in experimental.

But if you have packages depending on libimobiledevice1, you might have to wait until #620065 is properly fixed so that libimobiledevice2 is co-installable with libimobiledevice1.

Update: integrated the explanation to reenable the desktop icons thanks to bronte’s comment.

People behind Debian: Adam D. Barratt, release manager

April 7, 2011 by Raphaël Hertzog

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now “Release manager”, a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen.

You could expect the release managers to have some rest after a big release, but it’s not really the case. With the long freeze, loads of “transitions” have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions.

He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam.

Who are you?

I’m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf.

As well as being on the release team, I’m a member of the maintainer teams for devscripts and lintian.

Can you describe your journey in Debian and in the release team?

I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels.

When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I’d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9.

As most readers will be aware, we unfortunately reached a point during last year where we didn’t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say…

How much time do you usually spend working for the release team ?

I’ve been trying to work out how to usefully answer this question. My initial answer was “approximately two hours each day”, but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I’ve decided to stick with my initial answer.

During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I’m reliably informed that at that point the correct answer to the question is “too much time”. 🙂

What’s your own retrospective of the Squeeze release? What went well and what needs to be improved?

Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause – communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle.

One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it’s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS’s blocking functionality to indicate reasons why a request cannot be fulfilled right now.

Are you in favor of time based freeze?

I think there’s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package.

One thing I’m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about.

What are your plans for Debian Wheezy?

The Wheezy to-do list I started before the final Squeeze release begins “multiarch, multiarch, multiarch”. It looks like we’re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I’m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so 🙂 and more transparent.

With my package maintenance hats on, I’d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian.

Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing “stable” can be accommodated to support this?

I’m not yet convinced that the concept of a rolling, “constantly usable” distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The “testing” distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release – that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don’t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions.

It’s been suggested that “testing” and “rolling” could be basically the same for most of the cycle, with “rolling” then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that “testing” was intended to avoid (i.e. the old “frozen” suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time.

What’s the biggest problem of Debian?

The thing that I’ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves.

That’s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a “do-ocracy” then we need to permit people the freedom to “do”.

Is there someone in Debian that you admire for their contributions?

All previous release managers, for making the job look much easier than it seems when you’re in the “hot seat”. 🙂

Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.


Thank you to Adam 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.

  • « Previous Page
  • 1
  • …
  • 56
  • 57
  • 58
  • 59
  • 60
  • …
  • 68
  • Next Page »

Get the Debian Handbook

Available as paperback and as ebook.
Book cover

Email newsletter

Get updates and exclusive content by email, join the Debian Supporters Guild:

Follow me

  • Email
  • Facebook
  • GitHub
  • RSS
  • Twitter

Discover my French books

Planets

  • Planet Debian

Archives

I write software, books and documentation. I'm a Debian developer since 1998 and run my own company. I want to share my passion and knowledge of the Debian ecosystem. Read More…

Tags

3.0 (quilt) Activity summary APT aptitude Blog Book Cleanup conffile Contributing CUT d-i Debconf Debian Debian France Debian Handbook Debian Live Distro Tracker dpkg dpkg-source Flattr Flattr FOSS Freexian Funding Git GNOME GSOC HOWTO Interview LTS Me Multiarch nautilus-dropbox News Packaging pkg-security Programming PTS publican python-django Reference release rolling synaptic Ubuntu WordPress

Recent Posts

  • Freexian is looking to expand its team with more Debian contributors
  • Freexian’s report about Debian Long Term Support, July 2022
  • Freexian’s report about Debian Long Term Support, June 2022
  • Freexian’s report about Debian Long Term Support, May 2022
  • Freexian’s report about Debian Long Term Support, April 2022

Copyright © 2005-2021 Raphaël Hertzog