Automating mainline kernel testing procedure
What is this session about?
This session is about simplifying the process of testing the mainline kernel. In triage we often use a canned response to have users download and test mainline kernel. We use this response so frequently that we should make it much simpler to test.
What seems to be the problem Officer Tux?
The problem is that the current instructions [1] are complicated for average user to understand. We have to remember that we have experience doing this, average users usually do not. What happens to most hardware bugs is that they get reported against linux, QA asks the user to test mainline. At this point the user give up or do not follow up, expiring the bugs.
So the bug is expired. Problem solved! Right?!?
The issue is still present, we have simply alienated a user by asking them to preform a task outside their comfort level. We assume that if you are technical enough to file a bug you can install a kernel. And if you don't do the testing we won't look at your bug. The assumption that a user is technical enough to file a bug is incorrect. Apport and Launchpad make reporting bugs extremely simple meaning there is no technical requirement, other than running ubuntu-bug and having a Launchpad account. As part of crossing the chasm, we need to make reporting kernel issues and assisting kernel developers a simpler process. Bottom line is that changing the existing mainline test process will result in less expired linux bugs.
What are some suggestions to create a simpler process for testing the mainline build?
- Generate a minimal LiveCD with the mainline kernel to simplify testing. Simply boot, test and report back a yes/no.
- Place a "mainline" metapackage in the repos for testing purposes
Are there any risks or disadvantages involved with this suggestion?
- Meta Package: A user (not knowing that shift brings up GRUB's menu) may be stuck at a terminal. Mainline does not support all video as well as ubuntu-patched kernels.
- CD Image: Not ideal for bandwidth, but safe and simple. Need too see how much we can strip out.
Blueprint information
- Status:
- Not started
- Approver:
- Pete Graner
- Priority:
- Undefined
- Drafter:
- komputes
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by