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!
