Entries by Marc Brockschmidt

We are currently having the fun of a perl update in unstable - most packages have been rebuilt and work just fine, now cleaning up the mess starts. Please don't expect perl to enter lenny in the next few days. Also, hold back on the uploads of perl packages or SONAME bumps, thanks. For the moment, I'm keeping my todo list in my hint file. If you would like to help out, just pick one of the bugs listed there and do the work, thanks :)

Some people expressed some concerns about the fact that we currently have about ~440 bugs in testing, but still hold to our plan of releasing in september 2008. The development of the RC bug graph as seen on bugs.debian.org is in fact not very promising - but using the information the BTS now keeps through version tracking, a more detailed graph can be created. This one in fact shows how nicely we are progressing: The number of long-standing RC bugs is steadily shrinking, while the number of fixed bugs just waiting for transition is increasing. The latter is due to several complex transitions that are stuck (such as the ghc upgrade to 6.8, the suitesparse upgrade or X.org). Anyway, lenny's overall situation is a lot better than the simple RC bug count shows, so try to be positive and start bug-fixing now, for the first Debian release on time!

In other positive news, the first bits of Gnome 2.22 have reached testing, we will switch the default gcc version to 4.3 on this weekend and will start using python2.5 as default python version in the next week. Interesting times!

In my first post about my current problems with Debian, I noticed that there doesn't seem to be a common vision of Debian's future. My last post was about Debian's current state of moving from stable release to stable release without actual aims.

Today I would like to rant about our lack of enthusiasm. Could you name the biggest new feature of Debian Etch? I think the graphical installer is very cool, it made the installation look a lot friendlier and made translations to languages not based on the Latin alphabet easier. But what else happened in Etch? We added SecureApt, which might be cool if you are a hardcore hacker, but leaves most people bored. The same is true for using UTF8 for new installations and the addition of udev to the default install. If you don't know where I got this impressive list of thing - look at the Debian Wiki.

Most of the things listed on that page miss the bling we see in other distributions. Ubuntu 7.10 introduced Compiz bling while Fedora 7 had full NetworkManager support and tried to "just work" [tm]. Yeah, Debian isn't that far away from such things, whenever we release, such things are also picked up. But somehow it doesn't look like people would get out and party because we include the newest and coolest feature - no, Debian Developers prefer to discuss such things as the default MTA.

Of course, we need to discuss the default MTA - and exim4 might not be perfect for the job - but we should also start to think about advertising the features that impress non-geeks, so that we can go out and say "Hey, lenny came out and now we have a full dependency based init system and a smaller MTA and our kernel is now completely free of binary blobs" to our geek friends, while our non-geek friends can hear about the new easy-to-use and beautiful desktop environments and configuration applications that allow them to just install and use their Debian, without moving to a command line once.

We are half-way there. Debian is cool. Debian becomes better every day (*cough* please look away from the RC bug graph, thanks). We should start telling people about it and have fun doing so.

Even though Adrian von Bidder suggests that I'm starting a bit early with the DPL campaigning, I thought I could add a few more thoughts to the blagosphere.

Adrian suggested to make the discussion of our of "vision of Debian" a regular event on debconf - I think it's a nice idea, but that doesn't mean we should keep silent about that topic the rest of the year. I think one of the problems we see in Debian is that we are missing an aim to strive for. We are currently just moving from release to release, while more and more developers have actually lost interest in stable releases. The impression that a common ground like Debian 4.0 is irrelevant seems to prevail, because the people most vocal in our user base usually want to see the newest and shiniest software on their desktop. We have been spending more and more effort to cater to their wishes and have ignored the fact that a majority of Debian-based installations are not run by such people, but by system administrators who do mass roll-outs and neither want nor need the newest X.org with more *bling*.

Ubuntu, the biggest Debian-based distribution, has found its users by packing up new software behind a nice installer, adding some branding elements and then shipping it. Stability is an issue for Ubuntu, but they don't spend as much time as we do on eliminating the last seemingly important bug in some esoteric software package before actually releasing. That observation is the ground for one of my ideas: Our current metric to determine how far testing is away from a release is counting the number of rc bugs - it doesn't matter if the rc bug is X.org crashing for all people or if it is a policy violation in a package with 12 users. Perhaps we should start thinking about a new metric, keeping in mind that for a majority of users, some bugs matter a lot and some matter not at all. With the release of etch, the number of installations of popcon has risen a lot, so for the first time, we have actual usage data that could help us with such a metric. There are a few problems with that approach, though:

• Popcon data is inherently wrong, because single computer installations tend to have popcon, while large installations (like the one in Extremadura) don't.
• A majority of popcon users uses the last stable release, not the one currently in development.
• 3 bugs in packages seldomly used can be more annoying for our users than one central bug - you might be able to find a work around somewhere for something that happens to a lot of people, but a bug only hitting a few users will stay unfixed for a long time.

I don't have more time right now, so the rest of my ideas will follow in the next few days, so stay tuned or add me to your killfile.

Yoe seems to believe I see a cabal in Debian. Let me assure you: I don't - and if there would be a cabal, I would be part of it. I've seen most of Debian, played around with NM, the release team, have seen how our buildd network works (or, in the specific case of today: mostly works) and have close contact to people in all other core teams of the project. I still haven't seen a sign of a Cabal.

I believe that there are "clusters" of people who work better with each other, simply because they have known each other for years and developed trust, but that's nothing I would actually mark as problem. I do the same. Many of our core people have too much work to do, mostly because getting a job well done is usually reason to give you more tasks until your performance becomes abysmal. That doesn't mean that they are bad people or do bad things intentionally, but often, they don't allow people to help them - the usual reasoning is "new people need training, training needs time, time is what I don't have => no new people". Obviously, that argumentation is flawed in the long run.

Anyway, on to the more technical details:

• The real reason for not adding new architectures is that not one of the people able to do so cares enough to do it. That doesn't sound as nice as "I don't really know why we don't do it", does it?


• I haven't asked the security team to support backports, and I won't. volatile isn't under the supervision of the security team and works just fine.


• Most porting machines aren't "down", they are "locked down". See the list of Debian machines (which is, BTW, seriously out of date). Hardware failure is something completely different (though we might want to think about using Debian funds to replace broken machines, if needed), but restricting access is a sign of an overloaded team of system administrators.


• Dictating how a team should be changed is usually not a good way to do things - but there isn't another. A few of our core teams have failed to solve their problems on their own. Debian's job now isn't to stand by, watching and saying "He, that's bad. Maybe they'll fix the team in the next decade". Also, there are people experienced with the tasks of these core teams who are not part of them - you might want to use their experiences.


• With my release team and unofficial buildd network hat on I will tell you that adding one buildd maintainer for those architectures that only have one at the moment would improve the situation a lot. Please don't assume that I only talk about stuff I have no idea of. Sometimes I actually know about things!


• I don't think that we need to change our position regarding the GFDL, but I do believe that we should work on our relation to the FSF. Debian is the biggest free-as-in-free-as-in-free-speech distribution on the market, so the FSF should actually be interested in working together with us. Still, that doesn't happen, so we should perhaps start by having a discussion what the problems of each of these organisations is in the eyes of the other.

And, FWIW: I do hate conspiracy theories too. They come to life because people usually want to see the "bigger picture" - even if there is none and all of the weirdness in their environment can be explained by chance, human error and unknown social problems. And as I said - I don't believe there is a group of people making decisions that seem bad for Debian. I just believe a lot of people try to do their best for Debian - but they fail on a regular basis.

It's this time of the year again: The one where I look back at my involvement in the project and decide that I've been a member long enough, so I should probably get out. For Debian, there are two ways to do it: Either become MIA or become DPL. As I have too many real life connections to other DDs, I guess I can't really do the MIA thing, so I should probably get elected as DPL. Whenever I consider this way out, I think about all the issues that make me unhappy about Debian. This time, I've written them down. So, here's a list of things I would like to see and would work on if I had the power to do so:

• Enforce addition of new architectures to the main archive. This includes kfreebsd-* and hurd-* - after all, we claim to be the universal OS. I've sometimes heard that our ftp mirrors wouldn't be able to handle the increased archive size - I don't believe that. We had the mirror split to work around this, not everyone is forced to mirror all architectures anymore. If actual Debian hardware should be a problem, we should use the money we collect to get the hardware we need.


• Make backports.org official, just like volatile. This doesn't mean kicking out the current team and give the responsibility for bpo to the dysfunctional ftp-team, but simply move the service as it is into Debian. A start for that would be to add backports.debian.org as CNAME for backports.org and then add fitting hints to our release notes.


• Resurrect the practice of porting machines. In ancient times, Debian had all kinds of machines available to all developers so that they could log in and debug architecture-specific porting problems. Nowadays, Debian collects hardware, Debian's hardware collects dust and Debian's BTS collects porting bugs. At the moment, most of these machines are not available to the developer body and access is granted to only a handful of persons besides DSA.


• Fix the constitution, so that the ftp-team, the account managers, the buildd admins, the system administrators and all other teams that currently don't see themselves as delegates of the DPL can in some way be changed when they are not doing their job. There is currently a GR for that in preparation, see the excellent proposal from Josip Rodin for more information. When that is done, we can turn to actually fixing those teams, starting by giving full permissions to active people that currently have only restricted access (ie Joerg Jaspert should be able to modify the LDAP holding Debian's account data and should also get to act as full ftp-master, not only -assistant). There are also quite a few people experienced with the tasks of the other teams, so we should add some of these people soonish.


• [Not really depending on DPL super cow powers:] Work on half-releases, like etch + 1/2. Besides adding a newer kernel for hardware support and updating the installer, we could think about adding backports packages to update desktop stuff. Many people seem to be interested in that.

Besides those things that I really miss in Debian, there are also a few things I would simply like to see done in the near future:

• Add more buildd admins.


• Resolve our conflicts with the FSF, get them to accept that we don't like the GFDL and then go on with lobbying for free software.


• Improve our appearance on conferences by creating common Debian material. This means creating "official" ISO images for DVDs from time to time (just like they are done by people for a specific conference from time to time), creating official information material that can be translated by the l10n teams, discuss guidelines for the people behind the booth (like "Please don't wear a shirt which allows visitors to see what you've eaten in the last week") and give advice for presentations.


• Clean up the DD list, so that we stop telling people that there are ~1000 DDs if only ~600 actually work on Debian. Yes, work on that is already on the way.


• Create a place (a ML, wiki page, pseudo package) where Debian people can simply drop interesting ideas. Often, busy developers have great ideas for new projects, but lack the time to actually implement them. Usually, the inside knowledge is only needed to conceive the idea, not to implement it, so we should have a place where people with free time at their hands can find great ideas. It shouldn't be needed to actually describe every detail of your idea, it should be more like "Wouldn't it be cool to collect all left socks and then get to world domination by tying them together?". This could also be the basis for a bounty system (and of course for the GSoC people)


• dpkg development - symbol-based shlibs look almost ready, but what happened to Wig&Pen alias dpkg-source v2?


• At some point, we should discuss our vision of Debian. I guess we won't find a common one, but it would be interesting to see where people want to see Debian in 5 (or 10) years. Should we "just" be a supermarket so that CDDs and forks can be based on us? Should we work on reintegrating all those efforts into Debian proper? Is that even possible?


• We should create a team (or, preferably, a DPL delegate) whose sole task is to communicate with the rest of the Debian ecosystem, so that common problems can be noticed, discussed and solved. I have to admit that I have lost track and couldn't say how many distributions are using Debian as their basis nowadays, but there seem to be quite a lot. I wish for a place where I can find such information (or at least a person who I can ask about it).

So, what do you think? Are all of those ideas crap or should we perhaps try to implement them? Have I missed something important?

So we had one of our german cabal meetings a few weeks ago. They happen seldom enough, seeing how we already control most of Debian. Anyway, I think you would be surprised how formal these meetings are:

In response to my rant about Debian's BTS, I got some mails about other project's handling of bug tracking system - I'm still looking through those.

More interestingly, Joey Hess blogged about it and defended keeping old bug reports - which I also think. I explicitly talked about bug reports with no activity and no maintainer reaction. I took the time to look at some of the bugs Joey submitted and found some good examples for bugs and packages that obviously need help.

230485 is now in the ripe age of nearly three years. Almost three years is also the age of the last mail to that bug report, which was one maintainer setting the severity to important, without a comment. Since then, there has been no note if this bug is going to be fixed, how, when, why and who is going to do it. A user might get the impression that the maintainer simply doesn't care about this (or other) bugs. That's not a good thing, I believe.

271752 is also a good example. The bug seemed to be unreproducible, now someone found a way to reproduce it and ... nothing happened.

206605 is also weird - a patch is there (and we're talking about little grammar change here!), but no upload actually included it. Without a comment why it is not happening...

Keeping old bug reports to inform users of existing problems is OK. But not fixing bugs (or even trying to fix them) is a problem!

Blogging is hard, isn't it? Finding a topic that's not better placed on specific mailing list or somewhere else is not easy. One of the classical subjects for bloggers is ranting. And that's what I would love to do now :-)

I have had discussions with people who are turning away from Debian in the past few months, mostly to Debian derivatives like Ubuntu. Mostly, the reason for that is some sort of software that is newer/better supported/blabla in some other distribution, which I think is OK. Debian has a policy of a long, painful release cycle, but the stable releases that come out of it tend to be useful for a long time and relatively bug-free. That is good and shouldn't be changed without good reason.

Most of the people I spoke too revealed a far more disturbing thing: The long release cycle isn't the only argument against using Debian. Most of these people had other reasons, and a good number of those are things that Debian as a whole can - and should - address. Mostly, the Debian BTS comes up as a topic. Not because we don't use the Industry Standard [tm] bugzilla (which I personally hate so much I can't even describe), but because the BTS contains a lot of old bugs nobody cares about. Look at most of our packages: Bugs filed 7 years ago, with the last activity from that time, without a hint how (and if) they are ever closed are not uncommon; they are what you actually expect if you look at a bug list.

Naturally, processing, forwarding and closing bugs is the task of the maintainer. This doesn't work out in all cases, we have more than one cases where maintainers are overwhelmed by the sheer number of bugs flowing in against their packages. Also, and that is probably accepted everywhere: Bug processing is uncool. It is so much more fun to rewrite your code, add features, get new packages in the archive and doing new, blingy stuff, that the boring maintenance work of existing packages moves to a place far down on the todo lists. But hey, this maintenance. That's what maintainers are for. Most Debian Developers are Package Maintainers. They should do it, not adding new stuff.

We need to discuss how to work around these issues. We are not the only project which an overfilled bug tracking system. Look at the Gnome and KDE projects, the number of bugs filed against Mozilla products each day. Can we learn something from them? I would be happy to get a bit of feedback about this, so whoever is involved in other projects which have found better days to deal with bugs, please send a mail.

Apart from the fact that I would love to get more input on this, I want to start something new for lenny, the stable release planned after etch. I want to get the bug count down. Not the release critical bug count (which is eagerly watched all the time), but the small issues that bug users every day. For that, I have planned to look at 5 random important and normal bugs each day (starting with software I use) starting the day etch is released. I may begin to do this earlier, but I'm currently really not swimming in free time.

I don't plan on fixing all these issues (well, I may, if I can easily reproduce them), but more on forwarding them to the appropriate place, upstream, and noting so in the BTS. I want to poke maintainers long enough to invest some more time in fixing bugs. This will also help with the MIA efforts of the QA team, I guess...

Oh, what I almost forget: I expect help from all of you!

I haven't blogged in a long time, so I probably should drop some thoughts here to show that I'm still around.

In the past few months, I have been able to dump some of my work on other people by orphaning some packages and getting Christoph Berg (Myon) to do Debian Front Desk work.

To compensate this loss of tasks, I became a member of the release team, so the recent discussions about funding release managers should probably interest me, but I fear the threads on debian-private, -project and -vote have only made me sick. The number of people who have been childish, unjust and simply weird is enormous and would be a good reason to leave Debian altogether, something which I considered a few times over the last weeks. I would surely quit a job where co-workers hate each other that much, so why should I do this to myself in my free time?

Interestingly enough, actual work for money has shown me why Debian is something that should be supported, even if the mailing lists are full of posts from idiots. I had (and have) to work on OpenBSD for a customer, porting the recent release of Gnome 2.16... Well, let me tell you, Debian is better. A lot.

I think this may help you if you're doubting that working on Debian is sane: Remember that we work together to create the best possible, universal operating system. And even if we're not there yet (and there's a lot of work left), we have succeeded in creating an useable, useful operating system, which is easy to administrate and allows you to have a lot of fun with it. And we did that together, in the occasional moments when fighting with each other wasn't that important.

I have to admit that I haven't invested a lot of time to work on Debian in the last few weeks, but this was due to personal and work reasons. In two weeks, I'll have to return to my usual university schedule, so I'll spend a lot of time on Debian ignoring the exercises I'm supposed to work on.

Also, I have been working on a new server I've rented together with Andreas Barth, playing around with Xen and starting to bootstrap the actual systems we will need. This will mean that I'll have to move my mail and web services in the next few days. I think I'll also move my blog to the new box, but I need to check out how to do this without flooding the planet...