| | 1 | = How to file a bug = |
| | 2 | |
| | 3 | As in any other complex software system, there will inevitably be bugs in the HelenOS source code (unless we can formally prove the opposite). It is therefore essential for people who run into them to make sure the bug is actually known to the developers and that all potentially relevant information that can help to root-cause the bug is available. This is best achieved by filing a ticket in our bug tracking database. Below follows a list of tips for filing the most useful bug reports: |
| | 4 | |
| | 5 | * Pick a descriptive ```Synopsis``` |
| | 6 | * '''bad''': ''HelenOS is broken'' |
| | 7 | * '''good''': ''page_ht_lock mutex taken while tlblock spinlock held'' |
| | 8 | * Categorize the new bug using fitting ```Type```, ```Component``` and ```Version``` fields |
| | 9 | * In the first comment section, provide a concise and complete problem statement |
| | 10 | * Say what deviation from the expected behavior you observe |
| | 11 | * Briefly say what you think the expected behavior should be |
| | 12 | * Include instructions, code fragments to reproduce the problem or state that the problem is not easily reproducible |
| | 13 | * If you set the ```Version``` field to ''mainline'', provide the exact revision of the changeset where the bug was observed |
| | 14 | * If the bug was observed in multiple revisions, specify the first one in which the problem occurred |
| | 15 | * Provide reasonable details about the hardware of the target system, such as: |
| | 16 | * the processor architecture, if not already clear from the ```Component``` field |
| | 17 | * number of processors |
| | 18 | * name and version of the simulator/virtualizer, if the target system is a simulated machine |
| | 19 | * Provide reasonable details about HelenOS configurations |
| | 20 | * consider including Makefile.config from the root of the HelenOS tree |
