KernelKarmicBugHandling
Launchpad Entry: kernel-karmic-bug-handling
Summary
It has become apparent that the incoming volume of kernel bugs has become problematic to manage. The ratio of incoming bugs to resources available will not scale as the volume continues to increase. The goal of this spec is to introduce better bug management workflows and practices to combat this growing number of bugs.
Release Note
Due to the high volume of incoming kernel bugs an improved approch to bug management is being introduced. See KernelKarmicBugHandling for more information.
Rationale
At the time of the Jaunty 9.04 release there were over 5000 open kernel bugs. That's a 1300+ net increase in bugs compared to the number of open bugs when Intrepid released. The kenrel team can not realistically be expected to close 5000 bugs in a single release cycle. If the total number of incoming kernel bugs continues to grow at a faster rate than the existing number of bugs can be closed, it's obvious that a new approach to dealing with the incoming bug volume needs to be addressed. Otherwise the probability of a critical or high priority bug not being seen by the kernel team becomes a greater concern.
User stories
- Bob reported a bug originally against Hardy and hasn't updated his bug since. However, this bug remains open and contributes to the large volume of bugs that must be tracked. This bug should be closed.
- Sue reports a high impact bug against the Karmic Alapha release. Unfortunately her bug is lost amongst the massive volume of existing kernel bugs.
- Joe reports a regression he's seen from Intrepid to Jaunty. Again this bug is lost in the masses and continues to be a regression for Karmic.
Implementation
Below are a few ideas that have been suggested (some more drastic than others):
- Mark all open bugs as Won't Fix after every release. Reporter must reopen the bug once it's confirmed against the latest development kernel.
- Consider some exceptions, like don't close bugs tagged regression-*
- Alternatively consider closing out all old Incomplete kernel bugs. These account for 1400+ open bugs.
- Also consider closing out New, Confirmed, Triaged bugs which have not had a comment for say 2+ months.
- Only allow Ubuntu specific kernel bugs to be reported. If the bug exists upstream it should be reported upstream. Ubuntu kernel devs can help resolve bugs reported upstream.
- Modify the bug reporting process to incorporate a series of questions to be answered such as:
- Is this a regression?
- Have you tested the upstream kernel?
- Has this bug been confirmed against the upstream kernel?
- How reproducilbe if this bug? What are the steps to reproduce?
Test/Demo Plan
A wiki must be created to document any changes to the bug reporting/triaging process.
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.