KernelLucidBugHandling
Launchpad Entry: kernel-lucid-bug-handling
Created:
Contributors:
Packages affected:
Summary
It is still apparent that the incoming volume of kernel bugs remains problematic to manage. The ratio of incoming bugs to resources still doesn't scale. The goal of this spec is to re-evaluate our current bug management work flow and practices and determine a more effective way to manage kernel bugs.
Release Note
Due to the increasing volume of incoming kernel bugs an improved and sustainable approach to bug management is being introduced. See KernelTeam/KernelLucidBugHandling and KernelTeamBugPolicies for more information.
Rationale
During the Karmic cycle we started implementing Kernel Bug Days as well as writing kernel arsenal scripts to combat the growing volume of kernel bugs. If we stop to look at the numbers, up until Karmic Beta we were seeing much better improvements compared to Jaunty. In the 5 month time span between Karmic opening and Karmic Beta, there was an increase of ~1000 open bugs of which the bugs in a New state increased by ~300. Compare that to the 5 month time span between Jaunty opening and Jaunty Beta, there was a far less total increase of ~300 open bugs but the bugs in a new state increase by ~750.
However, then Karmic Beta landed and we were completely smothered with the increased bug volume. Again, just looking at the statistics, between Karmic Beta and Karmic Final (a time frame of less than 1 month), we saw an increase of ~1500 open bugs of which the bugs in a New state increased by ~1250. Compare that to the time frame between Jaunty Beta and Jaunty Final which saw an increase of ~900 open bugs of which the bugs in a New state increased by ~700.
Then we compound this with the fact that things like kerneloops wasn't disabled until after Karmic's Final release and in the 1 week following Karmic's release, we saw an additional increase of ~1200 open/new bugs.
It's obvious that we need to continue to examine our current bug management work flow and determine how we can effectively deal with this ever growing volume of kernel bugs.
User stories
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.