Launchpad Entry: kernel-maverick-bug-handling
From the Lucid Blueprint: "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."
The growing number of bug reports will only continue to increase as we pull in more features to the kernel. With KMS we have seen a significant increase in bugs for modesetting and we have seen an increase of DRM related bugs due to the backport into the .32 kernel. These will all need to be addressed. The goal of this particular spec is to continue improving our automated processes along with defining better processes to address these and other subsets of bug reports.
We must improve our response time to issues in addition to improving our ability to detect duplicates and provide a higher level of service to our Bug reporters. failure to show a marked improvement in these aspects could result in a further loss of users or an increased unwillingness by bug reporters to verify fixes or check issues against mainstream kernels.
An additional, and I think more troubling, is a sharp unwillingness by kernel upstream to work with us in Launchpad due to several issues with the tool itself.
Process will need to be created/revised to help us understand first the 'how' of addressing these bugs. This will be beneficial to both community members who desire a growing understanding of how we do things and grow their personal involvement with the bug reports, and will allow us to develop the appropriate tools to address the issue programatically.
The issues with Launchpad will either be addressed via this spec or via a separate blueprint.
This need not be added or completed until the specification is nearing beta.
There is a potential need to spec for LP improvements later.
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.