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

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.

Journey of a new GNOME 3 Debian packager

April 11, 2011 by Raphaël Hertzog

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that’s not enough in this case, GNOME 3 is not fully packaged yet and it’s only in experimental for now.

I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there’s lots of work left. Instead Roland Mas gently answered me “Sooner if you help”. 🙂

First steps as a GNOME packager

This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I’m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org.

Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn’t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance.

Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version—usually 2.91—in experimental, but some are still at 2.30).

Packages updated and problems encountered

(You can skip this section if you’re not into GNOME packaging)

So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it’s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment.

Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log.

Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It’s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem.

In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus.

Help is still welcome

There’s still lots of work to do, you’re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don’t know).

Installation of GNOME 3 from Debian experimental

You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you’re ready to invest some time in understanding the remaining problems. It’s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues).

To help you out with this, here’s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500

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

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it’s better than nothing.

I hope you find this useful. I’m enjoying my shiny new GNOME 3 desktop and it’s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

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
  • …
  • 65
  • 66
  • 67
  • 68
  • 69
  • …
  • 102
  • 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