9 | | 1. Before reporting a bug please [/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority make sure] that it does not yet exist. You can also use the [/search?q=&noquickjump=1&ticket=on search] function for this. |
10 | | 1. Do not report build problems to the bug tracker, please use the haiku-development mailing list for this. We have automated tests for the default builds, though. |
| 9 | 1. Read BugTrackerEtiquette. This mentions what content is appropriate, where to seek additional assistance, and peculiarities with our bug tracker. |
| 10 | 1. Read BugTrackerEtiquette and yes, we mean this. |
| 11 | 1. Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.),. |
| 12 | 1. Mention which revision from SVN you are running. You can find this out in the 'About Haiku' application, in the Deskbar menu. |
| 13 | 1. After the bug has been reported, a developer will look at your bug. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding non-informative comments. |
| 14 | 1. Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Stay around to answer these. Consider your participation 'done' when the bug is marked as 'fixed'. Together we can improve Haiku, bit by bit. |
| 15 | 1. The remainder of guidelines depend on the type of bug: |
| 16 | 1. [#SoftwareBugs applications and other pure software] |
| 17 | 1. [#HardwareBugs hardware and its drivers] |
| 18 | |
| 19 | == Software Bugs == |
| 20 | |
| 21 | Before reporting a bug please [/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority make sure] that it does not yet exist. You can also use the [/search?q=&noquickjump=1&ticket=on search] function for this.[[BR]] |
| 22 | 1. If you find an existing ticket that is open, only add information that is not already on the ticket. |
16 | | 1. Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot. If it is a hardware problem, include a copy of the syslog file. |
17 | | 1. After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding non-descriptive comments. |
18 | | 1. Remember, reporting a bug is not something you do spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Stay around to answer these. Consider your participation 'done' when the bug is marked as 'fixed'. Together we can improve Haiku, bit by bit. |
| 26 | 1. Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot. |
| 27 | |
| 28 | == Hardware Bugs == |
| 29 | For the hardware related issues, it is preferred to always create a new ticket. In the ticket, be sure to include the following, preferably as text attachments. |
| 30 | * `listdev` (a detailed listing of your hardware, including vendor and pci id's, similar to `lshw` and `lspci`) |
| 31 | * `listusb -v` (assuming its a usb related issue, similar to `lsusb`) |
| 32 | * `open /var/log/syslog` (the primary system log used by Haiku, akin to on screen debugging during boot) |
| 33 | * `listimage | grep drivers/` |
| 34 | * `ints` (from within Kernel Debugging Land -- KDL ) |
| 35 | |
| 36 | Enter the kernel debugger by invoking ''Alt-SysReq-D''. |
| 37 | Then the `ints` command will output information about handled and unhandled interrupts . |
| 38 | You can get out of the kernel debugger back into a usable system by typing `co` (for `continue`). |