There are two main types of kernel bugs, those which fail loudly (oops!) and those which do not. I am not counting new hardware support bugs, as those are really feature requests. We have said many times recently, the Retrace Server
is getting a lot of attention. This is great, and quickly points out which of those noisy fails the most users are hitting on a given kernel release, and allows us to prioritize based on a combination of severity and the number of users hitting a given bug. It can make things easier to track down, because we might have some idea of which kernel introduced this bug, and hopefully there is enough meat to the entry for us to know where to start looking for a solution. Unfortunately, the second type of bug is not so clear. This is things like regressions in hardware support (my wifi worked fine in the kernel x, but no longer works in kernel y), and various other regressions where silently, things no longer work as they should/used to. What follows will hopefully make things easier in dealing with those second types of bugs.
There are three very important points that I should get out of the way first:
- Please test with the latest available kernel for the release you are running. Any fix will be on top of that, so it saves a lot of time and effort on both parts to know that the bug still exists in the currently supported kernel. When people file bugs against old versions, the first thing we will ask is if this is still occuring in the latest update. Basically nothing will happen towards getting your bug fixed until we know that it does.
- Search bugzilla, and make sure no one else has filed a bug on this issue, if they have, don't open a new bug, comment on the existing bug. Any new or relevant information can be a big help here. If you see something that looks similar, but not really what you are seeing, file a new bug. Adding that your wifi card doesn't work when docked on a bug about the same type of card not working at all will only cloud both issues, or get your issue ignored when the original is fixed and the bug is closed.
- Search google, and see if there has been discussion of this issue upstream or elsewhere. If there has been, mention that in the bug description, link to that external information. It saves us time, and can make a huge impact in how quickly your bug gets fixed.
As I am sure many of you are aware, bugzilla generates a lot
of email. While the web interface does have some interesting search capability, email is the main method of getting notified of new bugs. The better those initial emails (your bug reports) are worded, the more likely we can have a real understanding of the nature or priority of that bug. Now that retrace is decently usable, I tend to ignore any bugzilla mail from abrt and assume that it will show up in the retrace results if it is a high priority. That doesn't mean those bugs do not get addressed, only that we have a good system for prioritizing those outside of bugzilla. This saves time and makes it easier to actually read through the new bugs filed against the kernel in other areas. Bugzilla mail is sorted and works just like any other email list you might want to keep up with, only the "from" field is irrelevant, we can't see who filed the bug when scanning a mailbox. The first thing we see of any interest is the subject. Something generic here means I am less likely to take an interest after a long weekend when I have a lot of mail to go through, if your subject is clear and concise, this is more likely to grab attention. Even better if it includes the first kernel version where this bug was seen. Now that we have an idea of the actual issue, someone is more likely to take the time to read your description. Again, clear and concise is good, but actual detail is important. If this is a matter of hardware no longer showing up between two kernel versions, tell us which was the last known good, and which was the first known bad. Mention that a dmesg from bootup with each of those kernels is attached (and attach them!). If behavior changed, explain exactly how it changed, and if you can show output from specific tools which will help, mention it in the description, and actually attach that output. These types of details tell us that this is a bug where we have some idea of where to begin. These are the types of details which get me to make sure to open your bug into a tab so I remember to go back to it when I finish scanning the new bug mail. If this is a catastrophic failure, such as data corruption or the like, please mention that in both the subject and the description, it really helps us prioritize. Finally, when we ask for more information, please try to respond. Chances are, if we have asked for more information on your bug, it has been filed away as "done all I can do until I get a reply" which means I am unlikely to look at it again until I get an email saying there is new information.
Sorry this has been long winded, but it is something we on the kernel team spend a lot of time dealing with. Anything we can do to streamline the process and correctly prioritize will be a big help towards a better working Fedora kernel, and that's good for everyone.