RFC: Stable kernel updates and the SRU process

[Henrik Nilsen Omma]

Pete Graner wrote:

> Does upstream have this documented anywhere? I'm not comfortable 
> adopting a process based on someone elses that is not documented, 
> followed and enforced.
> 
> Additionally I would support this if we can get this tested across all 
> the hardware we have. This ensures we can boot and pass a functions 
> check of the major sub-systems.
> 
> cc'ing in heno for comment. heno you can find the full thread here to 
> get up to speed: 
> https://lists.ubuntu.com/archives/kernel-team/2008-October/003364.html

I generally support the proposed change provided that the SRU process be 
replaced with another rigorous QA process. It should focus on regression 
testing and broad hardware coverage.

We can definitely run automated tests across the hardware in our labs, 
but I would appreciate some help from the kernel team in extending our 
test suite for this. We currently run a fairly basic set of tests to 
boot, install and check for basic HW support. We are also equiped to run 
3rd party suites like autotest and ltp but we don't have the right 
post-processing set up for these. I think we should cherry-pick a 
selection of tests from these suites to run on each kernel version upgrade.

I'd also like for us to make these tests available to a wider audience 
so we can encourage users to test on a greater variety of HW while the 
new kernel is in -proposed. We should set up a tracking page to monitor 
feedback from users for each .y update (could be an LP, list or based on 
the SRU tracker or ISO tracker)

A QA procedure strawman:

* 2 weeks minimum in proposed and new uploads on the same .y cycle zeros 
the clock

* We need to be able to identify blockers for each .y release. I propose 
we set up a new project (ubuntu-kernel-updates?) that will have 
milestones like intrepid-update-1. We can then set a task and milestone 
for bugs reported during -proposed testing. High and Critical bugs 
should be regarded as release-blockers.

* There should be explicit sign-off from QA before a new .y update goes 
out, analogous to the role the SRU team plays now. I suggest Steve and 
Leann should form a board that would make that call.

Henrik