Automating mainline kernel testing procedure

Registered by komputes on 2011-05-07

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.

[1] https://wiki.ubuntu.com/Kernel/MainlineBuilds

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

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.