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!
