FEB
23
2005

KDE Bug Tracker Hits Report 100,000

With bug number 100,000 reported, the hard-working KDE bug tracking system reached a milestone today. However, not everyone knows what goes on behind the scenes and how to help. In this article, I take a short look at using the bug reporting system, and how you can help KDE improve.

To get such a large number of reports from users and developers of the
software takes some time. However, reports have been entering the
system since the early days of KDE back at the start of 1999. With
such an impressive amount of data in the bug database, it's worth
taking a look at how it's all organized and kept running smoothly, and
what you can do to help.

More than you might think

The KDE bug tracker doesn't just contain reports of crashes and
misfeatures in applications, but plenty of other information. If
there's a feature you'd like to see in KDE which others would find
useful, you can file a 'wishlist' bug requesting it. We'll look at the
best way to report wishlist requests shortly, but just keep this in
mind for the moment. And KDE isn't just code! You can also file a bug
against documentation if you find a problem with it - just use the
docs product. And the polished look of KDE is important too:
you can report problems with icons, wallpapers or splash screens in the
artwork category.

Getting involved

With dozens of bugs reported each day (as I write this, the system
tells me that 105 bugs were reported today alone), maintaining and
organising all that information is no small task. Although many KDE
developers put a lot of time into dealing with bugs, it's not always
the most efficient way for them to spend their limited time. And
that's where you can help. Bug triage is a simple but effective way to
get involved with KDE. The definitive guide is the KDE
Quality Team bug triage howto
, but here are some tips to get you
started:

  • Choose an application (or applications!) that you like and are familiar with, and
    watch bugs for that application. That way, you can judge more easily whether
    the bug is valid, and you'll rapidly become familiar with the bugs
    that are already reported.
  • Running a CVS HEAD or stable branch (KDE_x_x_BRANCH) version of
    KDE will allow you to check whether bugs have been fixed in the
    development version of KDE. It's a worthwhile payoff for the time it
    takes to compile a CVS version.
  • Consider working on bug reports for the Konqueror HTML renderer (KHTML). They're quite easy to test,
    and the quality team howto gives some good tips on how to produce test
    cases and so on.

If you'd like to help with bug triage, but aren't sure where to
start, drop the KDE Quality Team a line at kde-quality@kde.org. Remember,
it doesn't necessarily take a lot of your time, but can really help
KDE to improve.

Getting the most out of the system

Despite the hard work of all the KDE developers, bugs sometimes do
hamper your work in KDE. But, as a user, you're in a position to be
able to do something about it. The first line of attack is to file a
bug report on bugs.kde.org. There
are some easy ways to make sure that your bug report is as useful as
possible. Following them makes life easier for the developer reading
the report, and makes it more likely that the bug will be fixed, so
everyone wins.

The definitive guide to effective bug reporting is by Simon Tatham,
prosaically called How to
Report Bugs Effectively
. I won't repeat everything he says, but
just note some things that are particularly relevant to KDE.

  • Check carefully that the bug hasn't already been
    reported. Bugzilla has powerful query tools for this, so make sure you
    use them when reporting a bug. If the bug has already been reported,
    read the comments to see if there's anything useful you can add (for
    example 'this bug also occurs in the latest cvs version').
  • Work with the developer, not against him or her. It might
    seem like you're on opposite sides, finding problems in a programmer's
    code, but you have the same aim - fixing the bug. Provide any
    information about your system that the developer asks for, and test
    any workarounds that he or she asks for.
  • If you're filing a wishlist bug, make sure that you're clear about
    what you are requesting. A simple graphic or a mockup of what you'd
    like can sometimes speak louder than words (but put the words in
    too!).

In conclusion, the KDE bug database is a powerful tool for both
users and developers, and a great way for new contributors to give
something back to the KDE project. With a few simple guidelines, it
can be made the most productive possible, with very little pain. So
get reporting and triaging!

Comments

It's a milestone I wish KDE never reached. Konqueror has over 1700 bugs, should we celebrate when it has even more? I think not.

And I don't think KDE's path to bugdom is goodnews either.


By Al at Wed, 2005/02/23 - 6:00am

Computer programas have bugs. That's a fact. The KDE team and Free Software projects acknowledge that fact and they try to actually improve things, not to hide problems. Besides that, they pay attention to user's opinions and ideas. I can only thank them for their hard work.


By Anonymous at Wed, 2005/02/23 - 6:00am

Get serious. Mozilla is reaching 300000 in the foreseable future... and it's only a browser (+Mail+Chat+Composer+Xul+...).


By Harald Henkel at Wed, 2005/02/23 - 6:00am

Look at the bugs by application numbers. Do you notice a correlation?

The ones that people use have the most bugs reported. The ones that are not used, usually due to incompleteness, have very few bugs reported.

I am currently working around a bug in Konqueror < 3.3 that is fixed in the latest betas. How many bug reports are being generated by what has already been fixed?

In November 2002 when I started the Digest, bugs in the 50000 range were being fixed. That is just over two years. There were (by memory) between 2-3000 open bugs at the time. Konqueror was barely usable as a browser.

Are you suggesting that the higher bug numbers for Konqueror means that is it less useful?

Derek


By Derek Kite at Wed, 2005/02/23 - 6:00am

>Konqueror has over 1700 bugs.
Why don't you stop whining and lend a hand insted, I'll even point you to a easy target. No coding needed and it'll give you a better understanding of the bugdatabase and it's numbers. Go through the wishlist items on Konqueror and it's related modules, and find those already implemented. If you manage to identify for closing, lets say something like 10(negotiable) a day for a week, you'll get a price.


By Morty at Wed, 2005/02/23 - 6:00am

You don't "get it". There is no bug-free software (well, "Hello world!" might qualify as one....). The more the software is used, more bugs are reported. Just because the number of bugs is high, does not automatically mean that the software is buggy. Like it was already commented, Mozilla (a single app!) has more bugs than entire KDE does! Does that mean Mozilla is steaming pile of bugs?

KDE is growing. The codebase is getting bigger, and more apps and functionality is added to the system. And the number of users is getting bigger and bigger. And that means that number of bug-reports is going to increase. But that doesn't mean that KDE is getting buggier. Since there are now more reported bugs than there was in 3.3.0-days, does that mean that the current version (3.3.2) is buggier than 3.3.0 is?

Seriously: you can't simply stare at the number of bug-reports and decide that "this software is buggy!". If KDE-folks erased all bug-reports (so bugs.kde.org would show 0 open bugs) would that mean that KDE has less bugs? No it would not.


By Janne at Wed, 2005/02/23 - 6:00am

Well, "hello world" has a huge usability problem. I leave the details as an exercise to the reader.


By Roberto Alsina at Wed, 2005/02/23 - 6:00am

Sure. It assumes actually that you're able to *read*...


By c0p0n at Fri, 2005/02/25 - 6:00am

Nope, not that. Keep playing.


By Roberto Alsina at Fri, 2005/02/25 - 6:00am

try Crtl -- with Firefox , the eternal bug.


By Jakob at Wed, 2005/02/23 - 6:00am

there was/is a program where you get money if you find a bug in it, because it has nearly no bugs ! i think it was latex or tex.. can someone clarify ???

no bugs (99.9%) that woulb be cool !! its possible


By chris at Wed, 2005/02/23 - 6:00am

It's TeX. Donald Knuth pays $327.68 to everyone who discoveres a new bug in TeX or METAFONT and $2.56 for a new error in one of his books.
http://www-cs-faculty.stanford.edu/~knuth/abcde.html ("Rewards")

But notice:
- TeX development has been frozen long time ago. Knuth only releases bugfixes (seldomly) and insists that any successor cannot be called TeX.
- If Knuth had to pay every report, he would have run out of money. Luckily, the cheques itself became the most important thing, and the people didn't insist on the money. It has instead become an honour in itself to have a Knuth cheque.


By jojo at Wed, 2005/02/23 - 6:00am

Just to add to the chorus...

Bug report counts does not mean bug counts. There can be more reports for an application with less bugs.

Bug report counts do not take into account severity. Rather we have 10 cosmetic bugs that one crasher or dataloss.

Changes in bug report counts do not mean a proportional change in application quality. More reports means more bugs found, not more bugs existing.

The headline figures of 100,000 for KDE and 300,000 for Mozilla include *closed* bugs, too...

Certain news sites have tried to spin bug counts as an "increase in bugs" for Mozilla. No need to do the same for KDE. More reports are good, it's the first step to fixing them.


By a mysterious an... at Wed, 2005/02/23 - 6:00am

Put it the other way round:
Only 8000 bugs and 8000 withes are open.
That means 84000 bugs were closed over the years...

By the way:
Are the numbers really counted starting at zero/one?


By Peter at Wed, 2005/02/23 - 6:00am

> Are the numbers really counted starting at zero/one?

nope first bug was #100.

http://bugs.kde.org/show_bug.cgi?id=100

The first bugs where imported from the previous bug database.


By ac at Wed, 2005/02/23 - 6:00am

Are there any plans to include some form of automated crash reporting in KDE applications, something like Mozilla's Talkback?


By ac at Wed, 2005/02/23 - 6:00am

I get this feature already... using 3.4 beta 2. Not sure when it was introduced though, but I can seem to remember it being around for a little while.


By ltmon at Wed, 2005/02/23 - 6:00am

I seem to recall it in the 2.0 series. Though my memory could be faulty. So I decided to check when it was.

The authors file (rev 1.1 in cvs) has been in all the taggings since: KDE_1_91.

So, I think KDE has had it a bit longer than Mozilla. (I only recall seing the talkback within the last year or two. Though my memory could be faulty. )


By James L at Wed, 2005/02/23 - 6:00am

Your memory is faulty.

Mozilla has always had talkback, and definitely recall the same feature being even in Netscape 4.x

In fact, Talkback is no longer available, so Netscape/Mozilla is one of the few *remaining* users. I think somebody said they have the source from escrow, but this is where my memory gets faulty :)


By a mysterious an... at Wed, 2005/02/23 - 6:00am

I am not sure, but I think it is only activated in development versions.


By carewolf at Wed, 2005/02/23 - 6:00am

Does anyone have more information about that? I thought that one of the strengths of Talkback was some form of automated evaluation of the incoming crash reports, creating crash statistics, etc. Is this what the KDE crash handler does? Is there any documentation available on the web?


By ac at Wed, 2005/02/23 - 6:00am

My experience with public bug systems of major OS projects:
Especially noteworthy IMHO is that KDE developers really pay attention
to what's going on and voted for on bugs.kde.org and do not see
the non-developing bug-writer as an alien foe like mozilla.org does.
A good-written bug-report is at least processed/answered after some
time in most cases. This cannot be said for mozilla.org or even
worse OpenOffice.org which use the same (BugZilla) bug system but
where bugs lie around for ages. OpenOffice.org doesnt really seem
to care much about their bug list - it wouldnt be in that bad shape
otherweise. For instance I havent yet even been able to _find_ one of the
most prominent bugs in OpenOffice.org which keeps most of my colleagues
and me from switching: Word compatibility is astonishingly good but all
of this is spoilt because the distance between enumeration numbers
and the headline is measured from the number - not from the left margin
so all headlines are shifted to the right. You can of course manually
correct this but this would be way too complicated to do for all
docs. Lots of development is going on on improving the word import with
vector graphics and what not and such a basic issue is not corrected
even with the newest version. I would really be interested why this
isnt corrected but havent yet been able to find any information on this
"issue" as they call it ;-).
At Mozilla.org (I cannot say this for OpenOffice.org!) even serious non-trolling comments about bugs are often met with a somewhat hostile attitude. I suppose KDE has the advantage of not having any corpprate
origins and thus is much more community-friendly. Kudos to everyone
involved!


By Martin at Wed, 2005/02/23 - 6:00am

"For instance I havent yet even been able to _find_ one of the
most prominent bugs in OpenOffice.org"

This reads as if you have searched for a bug report for this issue, have been unable to find one, and have not filed one. If that's the case, why haven't you filed a bug? I don't have much experience with bug handling in OOo, so it might be as bad as you say. But the bug will certainly never get fixed if you don't report it!

Sorry if I am pointing out the obvious, but the way your post reads makes it sound like you skipped this important step.


By Spencer Ogden at Wed, 2005/02/23 - 6:00am

Basically you are right. I actually do file bugs on KDE quite often.
But I don't file bugs on issues which are THAT obvious. This is
not a wishlist item or bug which happens only on some PCs or sth.
like that. I am *100%* sure they know about this bug. It's way too
obvious too ignore. Just open any word file with enumerations in
OpenOffice. Only the reason why this isnt yet solved is unclear.
Perhaps its too risky to do before a 2.0 release. It's just the reason
why they havent fixed it yet why I wanted to find the
corresponding bug report.


By Martin at Wed, 2005/02/23 - 6:00am

There is no argument for not reporting the bug. The fact that you understand the bug so well would definely help them fix it.

There is no problem in reporting a bug that is obvious or that everybody knows about. Bug systems are designed to deal with that.

*Not* reporting *is* a problem. For you, at least. It's like you wanting to win the lottery without ever buying a ticket.


By Fabio Gomes at Wed, 2005/02/23 - 6:00am

That bug might be obvious to you, but it isn't to me. File the report, because it is too easy to overlook things.

Even in the case of the obvious, sometimes there are so many obvious bugs that you don't know where to start. When you say one is holding you back, filing the report tells everyone that someone cares about this one, so they are more likely to fix it now. Otherwise they may spend there time fixing some other obvious bug that nobody cares about.


By bliGill at Thu, 2005/02/24 - 6:00am

Thought you might be interested in Interpretations of Bug Tracking Software


By Joseph Reagle at Wed, 2005/02/23 - 6:00am

that was an impressive and well thought out paper IMHO. thanks for sharing it... i take it that it is/was part of your graduate studies? i'll have to go looking for more of your writings on the net now... *minutes pass* ah! i see you have a blog ... *trundles off to read*


By Aaron J. Seigo at Thu, 2005/02/24 - 6:00am

> I suppose KDE has the advantage of not having any corpprate
> origins and thus is much more community-friendly

nah. we just have a policy about how often people in the project must get laid.

we've found that a regular schedule followed rigorously helps decrease inner tension thereby increasing one's ability to deal with others. those who can't keep up with the schedule tend to migrate to other projects, bringing their tensions and irritability with them.

oh, and a sense of humour helps too. ;)


By Aaron J. Seigo at Thu, 2005/02/24 - 6:00am

There is a whole chapter n Cryptonomicon where Waterhouse explains this. With graphs.


By Roberto Alsina at Thu, 2005/02/24 - 6:00am

ok look i'm a newbe to this stuff but im computer told me to report a KMix control prob to this page so i am i'm running a Linux OS


By Blue at Wed, 2007/12/26 - 6:00am

Yeah, that title sounds awful. But, really, it is.

One of the nicest things about reporting bugs to KDE is how nice everyone is. I try not to repeat a bug or make a badly worded report of just post something silly, but I know that I have stuck my foot in my mouth before, so to speak.

On most projects, the developers give people crap about something like that. I've never gotten an insult for something like that on KDE, not even a harsh word, even when I've accidentally been insulting.

Common wisdom would imply that a corporate community, which has to keep its users happy, would be better at being polite. Well, KDE is pretty good proof that such common wisdom is crap. Corporate run sites and corporate backed projects are commonly horribly rude, slow to react, and generally insensitive, but a completely open group like KDE is always polite and prompt.

So, I'd just like to say thank you to all the developers (and offer an apology to anyone on the team that I've accidentally been rude to before).


By jameth at Wed, 2005/02/23 - 6:00am

Full ACK!

And this is not just true for bug reports! I've found that the KDE project is one of the most forthcomming and freindly gangs of über cool hackers ive ever encountered! I've never been given a rude "RTFM" style answer, been called a n00b, been discriminated against for using gapp instead of kapp, or been ridiculed/flamed for my personal beliefs (OSS vs. FS etc.).

This alone makes KDE a really outstanding project! The general maturity and relaxed atitude that the average KDE-developer/supporter/docwriter/translater posseses really reflects the strength of OpenSource when its done right!

Many thanks for the great work that you all give me for free... But twice that amount of thanks for the community that you let me be a part of!!!

~Macavity


By Macavity at Wed, 2005/02/23 - 6:00am

Also translation errors can be reported against product "i18n" and your language as component.


By Anonymous at Wed, 2005/02/23 - 6:00am

Might it be as it is but what really strikes me are the many obvious bugs in KDE which offen lead into a crash of a whole application and the bugs which seem to be fixed in one release but reappear in some relese afterwards.
There is still another thing which I don't like not only in KDE but also other programms and application and that's the noice produced by the compiler when compiling and app from source it always seems as if much code is not written very clear:
(Comparisons between singed and unsigned ints, unused variables, uninitialized variables...)
Sometimes it seems to me that some programmers do not pay much attettion to this and these are mostly things which are easy to fix and make everything alot cleaner and better to compile.


By Mephi at Wed, 2005/02/23 - 6:00am

> Might it be as it is but what really strikes me are the many obvious bugs in KDE which offen lead into a crash of a whole application and the bugs which seem to be fixed in one release but reappear in some relese afterwards

Sometimes crashes only happen on your system. So what seems obvious to you might not be happing on the programmers machine.

> There is still another thing which I don't like not only in KDE but also other programms and application and that's the noice produced by the compiler when compiling and app from source it always seems as if much code is not written very clear:
(Comparisons between singed and unsigned ints, unused variables, uninitialized variables...)

Patches are always welcome.


By ac at Wed, 2005/02/23 - 6:00am

>Sometimes crashes only happen on your system. So what seems obvious to you might not be happing on the programmers machine.

That is a usefull and informative answer that the poster will gain some sort of enlightenment from.

>Patches are always welcome.

That is about as usefull as "RTFM" and just on the edge of being rude, as it is very close to saying "Don't complain about it if you cant fix it yourself".

Please consider the idea that a post that sounds like harsh chritisism might actually be a combination of lack of technical knowledge and lack of english skills.
I doubt that you would have been so quick to fire the gun if it had been phraised like this: "I would really find it most enjoyable if the KDE coding guidelines were to include the mention that all lines that causes a warning should have a suitable #pragma around it".

Please do not take this post as a flamer or chritisism, as that is by no means what so ever the intention, but rather as a surgestion to exersice a patient, informative and gennerally über cool attitude towards people who do not happen to be in the know (or who happen to have another oppinion then yourself).

Yours sincerely, and with cool regards:

~Macavity


By Macavity at Wed, 2005/02/23 - 6:00am

>>Patches are always welcome.
>That is about as usefull as "RTFM" and just on the edge of being rude, as it
>is very close to saying "Don't complain about it if you cant fix it yourself".
Not really, and since you more or less takes the statement out of context it's you who try to make it sound so. The original complaint who got this answer was about compiler warnings. And it's more than fair to assume anyone actually caring abut compiler warnings, also are capable of providing patches to fix this. But of course he could have phrased the answer different, something like this: "Since the development resources available in the KDE project are limited, the developers tend to priorities the most important tasks. Compiler warnings are generally not important and tend to get low priority. But the developers are aware of this and always welcome patches to deal with this issue." In the end if you go around watching for reasons to get offended, you most likely are. Personally i find it rather pointless.


By Morty at Wed, 2005/02/23 - 6:00am

Please note that these are WARNINGS not ERRORS. The app wouldnt
compile if it was an ERROR.
WARNINGS (as the name already says) only warn you that something
_might probably_ be wrong. Often this is not the case and the
warning can be safely ignored.
Example:
----------
i:signed
j:unsigned
fetchvalue(i)
if (not checkvalue(i)) exit;
if (i>j) then print "Hello";
--------------
In this case a value i is read from some where
Then the value is checked and if it is not ok
the function is aborted.
Afterwards, i and j are compared. The compiler warns -
thinking that i can also contain negative numbers because
they are signed. But it isnt intelligent enough to find out
that part of the "checkvalue" check already was to check if it
is a negative number. So when the execution comes to the last
line of my little mini-script it is already clear that i is
positive.
To all programmers - this is of course very simplified ;-)


By Martin at Wed, 2005/02/23 - 6:00am

I never sayed that this was an error or bug I just sayed that it is noice produced
by the compiler which is not necessary. To take your example whould it really break this case to make j a signed it too.
At least the warning would not appear and as far as I see it the result would be the same.
I just think that it looks ugly and little bad style if one gets dozens of compiler warnings during compilation.
Yes, I know a signed int uses more memory than an unsigned but what about kicking out all the unused variables for that.
The third case are warnings concerning uninitialized variables.
Why int a; instead of int a=NULL; in the sources that would be one compiler warning less.
I never wanted to be harsh but on the other hand there is hardly any need for compiler warnings, they are mostly easy to fix without any disadvantage.
Look at projects like hydrogen not even 1 compiler warning during the entire compilation that's were compiling is fun ;)


By Mephi at Wed, 2005/02/23 - 6:00am

"Yes, I know a signed int uses more memory than an unsigned"

Where did you get this idea from ?
int's und unsigned int's are usually 32 bit (at least on 32 bit systems).
Ever heard of 2's complement ?

"Why int a; instead of int a=NULL;"

NULL is supposed to be a pointer, not an int, altough on some systems it is indeed defined as just 0. int a=0; would be correct.


By Harald Henkel at Wed, 2005/02/23 - 6:00am

Yes it would, because j and i both come from different APIs. The OS knows that j can legally be larger than 2^31 (for a 32 but machine), but less than 2^32, so unsigned int is a good choice. i on the other hand cannot be more than 2^31, could be zero, and we need an error return. Therefore we make i signed and set i = -1 on error.

Of course this is a complex case that can't be solved the obvious way. If we move to a 64 bit system, or even a different OS (KDE compiles for more than linux) the type of i or j might change. The compiler is correct to warn, it cannot know that i is positive in the given case, even if it could, the situation only works on a few systems (even when it is all supported systems).


By bliGill at Thu, 2005/02/24 - 6:00am

Your basic point about warnings is, of course valid, and I fully support it. Then again, as a (KDE) developer, I won't promise that I never let such a warning slip in.

But as a matter of principle, I generally don't initialise variables in the declaration unless I need to. Its a great way to have the exactly the compiler warnings you mention tell you about latent bugs.


By Shaheed at Thu, 2005/02/24 - 6:00am