Debian – Page 63

No freeze of Debian’s development, what does it entail?

April 28, 2011 by Raphaël Hertzog

The main feature of rolling is that it would never freeze. This is not without consequences.

Possible consequences

It can divert developers from working on the release

No freeze means developers are free to continue their work as usual in unstable. Will it be more difficult to release because some people will spend their time working on a new upstream version instead of fixing RC bugs in the version that is frozen? Would we lose the work of the people who do lots of NMU to help with the release?

It makes it more difficult to cherry-pick updates from unstable

No freeze also means that unstable is going to diverge sooner from testing and it will be more difficult to cherry-pick updates from unstable into testing. And the release team likes to cherry-pick updates that have been tested in unstable because updates that comes through testing-proposed-updates have often not been tested and need thus a more careful review.

Frozen earth

My responses to the objections

Those are the two major objections that we’ll have to respond to. Let’s try to analyze them a bit more.

It’s not testing vs rolling

On the first objection I would like to respond that we must not put “testing” and “rolling/unstable” in opposition. The fact that a contributor can’t do its work as usual in unstable does not mean that he will instead choose to work on fixing RC bugs in testing. Probably that some do, but in my experience we simply spend our time differently, either working more on non-Debian stuff or doing mostly hidden work that is then released in big batches at the start of the next cycle (which tends to create problems of its own).

I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we’re currently used to with testing.

The objection that rolling would divert resources from getting testing in a releasable shape is difficult to prove and/or disprove. The best way to have some objective data would be to setup a questionnaire and to ask all maintainers. Any volunteer for that?

Unstable as a test-bed for RC bugfixes?

It’s true that unstable will quickly diverge from testing and that it will be more difficult to cherry-pick updates from unstable into testing. This cannot be refuted, it’s a downside given the current workflow of the release team.

But I wonder if the importance of this workflow is not overdone. The reason why they like to cherry-pick from unstable is because it gives them some confidence that the update has not caused other regressions and ensures that testing is improving.

But if they’re considering to cherry-pick an update, it’s because the current package in testing is plagued by an RC bug. Supposing that the updated package has introduced a regression, is it really better to keep the current RC bug compared to trading it for a new regression? It sure depends on the precise bugs involved so that’s why they prefer to know up-front about the regression instead of making a blind bet.

Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository and to file RC bugs for any regression. And instead of requiring a full review by a release manager for all uploads to testing-proposed-updates, uploads should be auto-accepted provided that they do not change the upstream version and that they do not add/remove binary packages. Other uploads would still need manual approval by the release managers.

On top of this, we can also add an infrastructure to encourage peer-reviews of t-p-u uploads so that reviews become more opportunistic instead of systematic. Positive reviews would help reduce the aging required in t-p-u before being accepted into testing.

This changes the balance by giving a bit more freedom to maintainers but still keeps the safety net that release managers need to have. It should also reduce the overall amount of work that the release team has to do.

Comments welcome

Do you see other important objections beside the two that I mentioned?

Do you have other ideas to overcome those objections?

What do you think of my responses? Does your experience infirm or confirm my point of view?

Towards Debian rolling: my own Debian CUT manifesto

April 27, 2011 by Raphaël Hertzog

As you might know, I’m of one the people who promote the idea of having a Constantly Usable Testing (CUT). I will post a set of articles on this topic to help me clarify my ideas and to get some early feedback of other Debian contributors. I plan to use the result of this process to kickstart a broader discussion on debian-devel (where I hope to get the release team involved).

Let’s start by defining my own objectives with Debian CUT. I won’t speak of the part of Debian CUT that plans to make regular snapshots of testing with installable media because that’s not where I will invest my time. I do hope other people will do it though. Instead I will concentrate on changes that would improve Debian testing for end-users. I consider that testing (in its current form) is largely usable already but there are two main obstacles to overcome.

Testing without freezes = rolling

The first one is that testing is no longer testing during freezes. The regular flow of new upstream versions—that makes testing so interesting for many users—is stalled because we’re using testing to finalize the next stable version. That’s why I’d like to introduce a new suite called “rolling” that would work like the current testing except that it never freezes. Testing would no longer be a permanent suite, it would only exist during the freeze and it would be branched off from rolling.

Rolling should be a supported distribution

The second obstacle is not really technical. We must advertise rolling as a distribution that ordinary people can use but we should make it clear that it’s never going to have the same level of polish that a stable release can have. And to back up this assertion, we must empower Debian developers to be able to provide good support of their software in rolling, this probably means using “rolling-proposed-updates” more often to push fixes and security updates when the natural flow of updates is blocked by transitions or other problems. Some maintainers won’t have the time required to provide the same level of support as they currently do for a stable release and that’s okay, it’s not worse than the current testing. The goal is to treat it on a best-effort basis and to try to gradually improve the situation.

My goal for wheezy

This is the the minimal implementation of CUT that I would like to target in the wheezy timeframe. Having testing as a temporary branch of rolling is not a strict requirement, although I’d argue that it’s important to not waste resources towards maintaining two separate yet very similar distributions.

Should Debian embrace those goals?

Ignoring all possible problems that will surface while trying to implement those goals, can we agree that Debian should embrace those goals because it means providing a better service to a class of users that is not satisfied by the current stable release?

I will come back to the expected problems in a subsequent post and we will have the opportunity to discuss them. Here I just want to see whether we can have broad buy-in on the principles behind Debian rolling and CUT.

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.