Tips regarding bug reports
Guidelines for providing effective bug reports
Author: Ragnar Wisløff < ragnar at wisloff dot no >
The mailing lists get quite a few questions about why things don't work. From a developer's point of view, these questions are quite often incomplete. When that's the case, it takes more time to find a solution, because additional rounds of Q&A must take place before the necessary information has been collected and a developer or another user is able to provide a useful and sufficient answer.
In addition, it is always of great interest to the developers to get to know how the new or changed functionality actually works (or doesn't work). The hardware available to us for testing is limited. Therefore, it's very important that people other than the developers themselves use and test Skolelinux on as many types of computers as possible, running as many types of installations as possible. But it is also of utmost importance to provide thorough feedback from doing and running these installations, so that we may know what happened.
Below is a list of the information we must have in order to be able to help those in need:
- What did you do just before things went wrong? As detailed as possible, please, so that the developers and other testers are able to recreate the error.
- What happened, including accurate notes of any error messages and so on.
- What did you expect would happen? Why do you think what actually happened was wrong?
- Include a copy of any relevant logfiles like /var/log/syslog. In all error situations, it's useful to include
Then send the information above to the mailing lists. Please do this in English, if at all possible, as this allows all developers to help, instead of only those that speak your local language.
To all people who report on test installations, we also ask that the logs mentioned above be made available. Feel free to send them as email attachments, or put them on a website you have access to and send us the URL. If you do not have an network connection on the machine where Skolelinux is installed, you may copy the logs to a diskette and move them to a machine connected to the Net.
As a rule, it's unlikely you provide too much information.
Bugs should be filed against the Debian BTS when appropriate, to minimize the coordination needed to resolve.
Some Debian maintainers love feedback, even from external derived use of their packages. Others want only to deal strictly with Debian.
- Use Debian BTS for packages in Debian maintained by debian-edu
- Use Debian BTS for packages in Debian used as-is in Skolelinux
- Use Debian BTS for packages in Debian rebuild in Skolelinux, if the
- Debian package maintainer welcomes such bug reports.
- Use Skolelinux BTS for packages in Debian but rebuild for Skolelinux
- if the package maintainer is not explicitly interested in them
- Use Skolelinux BTS for packages only in Skolelinux.
When reporting bugs on Debian BTS, that are relevant for Skolelinux, it's a good idea to tag them with our Skolelinux usertag That makes them much easier to track. You can tag a bug with our usertag by sending a email to firstname.lastname@example.org with contents like this
user email@example.com usertag 123456 + debian-edu thanks
You can tag multiple bugs in each email by just adding usertag lines.
You can also usertag bugs when you create them, by adding headers like this:
User: firstname.lastname@example.org Usertags: debian-edu
German Version is here http://www.skolelinux.de/wiki/BugReporting
http://wiki.debian.org/DebianEdu/HowTo/BugPriority+Severity provides more info how we treat bug.