- 1 General
- 2 Bug Priorities
- 3 Debugging
- 4 Bug-links inside the wiki
You can submit bugs to the Bugtracker. But please first have a look if this bug is already mentioned somewhere. If it's already on the list, add your bug message as a comment.
The priority settings we use for the bugtracker are described here. Please note that this system is rather new, so by far not all tracker items have their priority set correctly.
|Priority (SF/Genie)||Description||User perception||Examples|
|9 / critical||Catastrophic bug||the application is completely unusable||
|8 / vital||A vital feature doesn't work||the application is partially usable (for testing), but it doesn't make sense||
|7 / important||An important feature doesn't work||the application is usable, but its not enough fun||
|6 / normal||A minor feature doesn't work||the application is usable, but it's less fun||
|5 / not set||The default priority when the item is created.|
|4 / low||Any other minor misbehaviour the user might notice||the application is fully usable||
|3 / very low||Any other minor misbehaviour only a dev can notice||the application is fully usable||
The above applies to bugs that happen reproducibly (on a dev's machine !) on all platforms and have no workaround. If one or more of these criteria are missing, priority suffers a penalty of 0.6 for each, rounded. So a bug in a vital feature (Prio 8) that only occurs on Macs and is not reproducible (1.2) will have Prio 7. If there is even a workaround (1.8) it will be Prio 6.
Or, if you don't like to calculate: if one or two of the criteria are present, it's priority minus 1. If all the three are present, it's minus 2.
In a professional environment, priorities are closely connected to a certain behaviour of the devs eg. working overtime.
In an OSS environment, a prio 9 or 8 bug still means "all hands on deck". For priorities < 8, devs are 'supposed' or 'asked' to fix them according to priority. They are of course still allowed to fix even the least important bug if they are in the mood to do so.
See our debugging site for more information on how to handle segfaults and crash bugs.
You can use the code
to link to an existing bug in the tracker. The above example will produce "#1234567" (bogus number)
For request use the code
(#1502802 as result)