KernelTeamBugPolicies
ContentsBRTableOfContents |
Triaging kernel bugs is a day-to-day effort, and can be very time consuming. Luckily, we have a lot of community members willing and able to help with this effort. In order to make sure everyone working on kernel bugs follows the same policy, this document will describe how to handle the kernel bug workflow.
Triage Days
This serves as a way for the KernelTeam to coordinate it's efforts in keeping the list of Unconfirmed/Unassigned bugs to a minimum. Our first and foremost effort on bugs is to triage the incoming list, and decide quickly if it's legitimate and/or requires more information. Just responding to bugs is a major effort.
The person assigned to a particular day is merely committing to making a best effort to work on the list that day. It is not meant to restrict them to working on the list for just that day, or to force them to retract for important work in order to handle the bug list.
Mon:
Tue: BenCollins
Wed:
Thu:
Fri: TimGardner
Simple rules
The HOWTO below really explains most of the details of working with kernel bugs, but this list of rules should help clarify some common mistakes:
Confirmed bugs are assigned to teams
When a bug is marked Confirmed it should be assigned to a team. In most cases this is the ubuntu-kernel-team. In other cases, noted below, bugs can be assigned to other teams. This rule implies that you should not have a bug in Confirmed state assigned to yourself. Once you take a bug to work on, it should be marked In Progress.
It also should be noted that Confirmed state should only be set by a person triaging the bug report. The bug submitter or other person experiencing the bug should not arbitrarily set Confirmed state.
Sound/Audio related bugs should be assigned to the the ubuntu-audio team.
PowerPC bugs should be assigned to the ubuntu-powerpc team. This means bugs that are specific to only powerpc, not bugs which are reported by a person using powerpc, when the bug can affect any architecture.
Other teams are to be ignored right now, as they are all manned by the ubuntu-kernel-team anyway.
Confirmed bugs should have Importance set
Bugs marked Confirmed should have their Importance set to something other than Undecided. If a bug is Confirmed, then there should be enough information to know how important it is.
Needs Info means assign to yourself
If you are working on triaging a bug report, and it requires more information, the bug should be assigned to yourself. Note, the Needs Info state can also mean that the person triaging the bug is still investigating the data and background in order to assess if the bug is Confirmed, so does not necessarily mean more information is needed from the bug submitter.
In Progress means you are working on the bug
If a bug is marked In Progress, then it should be assigned to yourself. Marking a bug In Progress means you are actively working on it. If you need to keep the bug marked In Progress for an extended period (greater than a week or two), then you should update it periodically with progress, or just put it back to Confirmed and assign it back to the appropriate team.
Cannot have Importance without Status
A bug should not be given an importance until it's status has been set, usually to Confirmed.
Bug triage HOWTO
Handling incoming bugs is a fairly common and well defined task. The outline below will help you gather the correct information, and process bugs so that they will be visible to the kernel team, and to others helping with these bug reports.
Unconfirmed/Unassigned
This is how bugs come in to the system. No new bug should come in with a pre-existing Status or Assignee.
After reviewing the bug, you should assess whether there is enough information to actually fix or reproduce the bug. In most cases, there is always more needed information. You should at this point, set the Status to Needs info, and assign the bug to yourself. Note that the Needs info phase is usually one of the longest, requiring requests from yourself, and replies from the bug submitter.
Note, you should never have any bugs assigned to yourself in the Unconfirmed or Confirmed state. Bugs in Unconfirmed should be assigned to no one, and bugs in Confirmed should always be assigned to the kernel team.
Most common information needed:
dmesg output
lspci -vv and lspci -vvn output
Please ensure that the bug submitter attaches these outputs as opposed to pasting them into comments.
If the bug report is a crash, then have the user describe what they were doing during this crash, and if they are able to reproduce it. Hopefully the crash doesn't completely lock the machine, so that dmesg can be obtained. If this is not possible, then ask the user if they can get the crash output with a digital photo of the screen.
Once all the required info is obtained it's time to decide where the bugs goes.
- If it turns out to be a bug in something other than the kernel, it should be re-assigned to that source package.
If the bug is not a legitimate bug (e.g. it was user caused), then the bug should be marked Rejected.
If the bug is a legitimate bug in the kernel, then it should be marked Confirmed and assigned to the kernel team.
Setting the severity takes experience. Generally speaking, if the bug is a crash, it should be marked as High. Most bugs will start out as Medium though.
Confirmed
Confirmed bugs should be assigned to the kernel team. When someone (either kernel team or community) wishes to work on one of these bugs, they should assign it to themselves, and mark its status as In Progress.
In Progress
Bugs marked as In Progress are expected to be worked on by the assignee in a reasonable amount of time. If the person handling this bug cannot fix it in a reasonable amount of time, it should be reassigned back to the kernel team, and updated with any information that may help fix it.
Fix Committed
Bugs marked Fix Committed are considered fixed by a patch committed to the git repository. Fix is not yet applied to the built kernel. It is expected that the next kernel upload will contain this fix. There is no determinate time for when this will happen though.
Fix Released
The hopeful final end of any legitimate bug is to be Fix Released, meaning that the kernel in the archive contains the fix needed to close this bug report.