Oneiric kernel bug process and handling

Registered by Jeremy Foshee

The process by which the Kernel Team addresses bugs is ever-evolving. As our goal is to make it more efficient with each cycle, this cycle will focus on 2 key groupings of kernel bugs Development and SRU. As such, we will be outlining and planning the process needed around that as well as the change in responsibilities for the Bug Triager and the SRU team.

Blueprint information

Status:
Not started
Approver:
Pete Graner
Priority:
High
Drafter:
Jeremy Foshee
Direction:
Approved
Assignee:
Andy Whitcroft
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Work items for oneiric-alpha-1:
[jeremyfoshee] work with SRU team and KRM to develop/define process for addressing development kernel bugs.: POSTPONED

Work items for oneiric-alpha-2:
[leannogasawara] Review bugs every milestone for Ubuntu/ drivers we disabled in the release, and notify KRM of any reports: DONE
[jeremyfoshee] Investigate feasibility of a further triage summit/open week session (DX team has voiced +1 for this, see dbarth): POSTPONED
[brad-figg] Develop/define process to address SRU release bugs.: DONE
[jeremyfoshee] refresh triaging wiki pages based on new process: POSTPONED
[jeremyfoshee] refine/develop process for addressing regression bugs: POSTPONED

Work items for oneiric-alpha-3:
[canonical-kernel-team] identify which scripts we no longer run which we should port forward (with the aim of 0 New bugs): DONE
[canonical-kernel-team] migrate updated scripts to the kteam-tools git branch: DONE
[canonical-kernel-team] refine/update tools to batch process bugs in all open states.: POSTPONED
[canonical-kernel-team] Generate specific hotlist for devel bugs focus: POSTPONED
[brian-murray] tag existing apport-kerneloops reports based off the subsystem (network, graphics) following Kernel/Tagging (bdmurray is happy to help): DONE
[brian-murray] modify apport so that apport-kerneloops bug reports get autotagged using the subsystem: DONE
[jeremyfoshee] define/develop process to deal with confirmed and triaged state bugs:POSTPONED
[leannogasawara] Review bugs every milestone for Ubuntu/ drivers we disabled in the release, and notify KRM of any reports: DONE
[jeremyfoshee] update linux bug reported acknowledgement to recommend that people tags their bugs using tags from Kernel/Tagging: POSTPONED

Work items for ubuntu-11.10-beta-1:
[leannogasawara] Review bugs every milestone for Ubuntu/ drivers we disabled in the release, and notify KRM of any reports: DONE
[jeremyfoshee] Improve documentation for installing a test kernel, mainline kernel, -proposed, -pre-proposed: POSTPONED

Work items for ubuntu-11.10-beta-2:
[leannogasawara] Review bugs every milestone for Ubuntu/ drivers we disabled in the release, and notify KRM of any reports: DONE
[jeremyfoshee] to ensure the janitorial scripts are running on an on going basis: POSTPONED
[apw] prototype a script which will simplify installation and removal of kernels: proposed, mainline kernels, and specific test kernels: POSTPONED
[apw] prevent mainline kernels becoming the default default kernel EVER :): POSTPONED

Work Items for ubuntu-11.10:
[jeremyfoshee] drive new state bugs to 0 and maintain 0 new status bugs daily: POSTPONED
[leannogasawara] Review bugs every milestone for Ubuntu/ drivers we disabled in the release, and notify KRM of any reports:DONE
[dbarth] structure tag page for DX, link to main tag page (using include on top level page): DONE
[jeremyfoshee] update the Tips and Tricks section in the community help page.: POSTPONED

[17-may-2011 apw] I am assuming that the drive New bugs to 0 task is mostly about working out what tooling we need and interfacing with bjf et al to get that implemented and running. Otherwise this seems like a reasonable start.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.