|Deletions are marked like this.||Additions are marked like this.|
|Line 5:||Line 5:|
|All bug reports should contain atleast the output of these commands:||All bug reports should contain at least the output of these commands:|
All initial bug reports should be left in the Unconfirmed and Normal states until the report is satisfactory for debugging.
All bug reports should contain at least the output of these commands:
dmesg > dmesg.log
lspci -vv > lspci-vv.log
lspci -vvn > lspci-vvn.log
For clarification the commands passed to lspci are v v for very verbose output and v v n for very verbose numerical output. The > symbol instructs that the output of the commannd be saved in the stated .log file.
These three files should be attached to the bug report (not pasted into comments, as it makes things harder to read, and formatting is completely broken).
Dmesg output may be annotated to show before and after problem occured (e.g. if a device is attached and does not work, annotate where in dmesg the device was attached so that messages related to the attachment can be isolated).
Also, dmesg output should be done as early as possible after bootup to avoid extraneous output.
The submitter should provide as much informatin as possible in regards to whether the bug exists in previous versions of Ubuntu. Where possible, test the latest development version as well. Whether or not the bug affects other Linux distributions, or stock kernels is also of importance.
If the bug report involves a crash, it is hoped that a kernel backtrace is available. If the machine does not completely lockup from the crash, the backtrace should be available in the dmesg output. If the crash completely locks the system, then the user should be asked to supply a digital photo of the screen to capture the crash.
Sometimes crashes occur in X, and so terminal access is not available (to capture the kernel backtrace). When this occurs, the user should try to recreate the crash at the console (Alt+F1). If this is not possible, then annotate the bug as such.
For the most part, kernel bugs should be assigned to the ubuntu-kernel-team. In many cases, however, a specific team is aimed at handling bugs in different sections of the kernel. These teams fall into two categories: Subsection specific teams, and Architecture specific teams.
When assigning to one of these teams, use the following guidelines. Remember that if a bug falls into more than one category (e.g. an IDE bug on powerpc), it should be assigned to the most relevant subsystem team (as opposed to the architecture team). Subsystem teams always take precedence on initial bug assignment.
Certain bug classifications below require additional info from the bug submitter. Be sure to obtain this information before moving the bug out of Needs Info status.
- ubuntu-kernel-team: Drop through when bugs do not fall into a specific category.
- ubuntu-server: Any bugs dealing with the -server kernels that are not reproducable on a standard kernel.
- ubuntu-audio: Any bugs dealing with the ALSA sound system.
- ubuntu-kernel-acpi: Any bugs dealing with ACPI, including hotkey features, cpu throttling, thermal detection, battery states, etc.
- ubuntu-kernel-network: Any bugs dealing with network drivers (ethernet, wireless, etc) or the network stack (IP, ICMP, UDP, etc).
- ubuntu-kernel-usb: All bugs related to USB and USB devices (except in cases such as storage, video, sound and networking, where the bug clearly has to do with that team as opposed to a general USB issue).
- ubuntu-kernel-video: All bugs related to framebuffers, VGA, DRM, video acceleration, Video capture, etc.
- ubuntu-kernel-storage: IDE, SATA, SCSI, RAID, etc.
Architecure specific teams. Bugs should be assigned to these teams when it directly relates to the system in question. E.g. when the kernel wont boot on such a system.
Once a bug contains all the relevant information, it can be assigned to the appropriate team, and moved to the Confirmed state. If information is requested from the submitter, the bug should be left in Needs Info state.
Bugs that have been assigned are then handled by the appropriate team, or someone acting on behalf of that team. Once a member of the team begins work on a bug, it should be changed to the In Progress state.