RFC: Stable kernel updates and the SRU process

[Tim Gardner]

Henrik Nilsen Omma wrote:
> 
> 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
> 

I didn't really intend to propose changing the SRU process. Is there any
reason that expanded hardware testing can't take advantage of the
existing SRU mechanism (which I consider to work pretty well) ?

Perhaps an alternative solution is to automate the submission of stable
patch SRUs, tracked as individual bug reports with their own regression
results. Or, we can just bite the bullet and submit the SRUs manually.
It'll only take a few tedious hours in most cases.

My real point is that there is much goodness in the stable updates and I
 don't want our current process or policy to prevent us from taking
advantage of them.

rtg
-- 
Tim Gardner tim.gardner at canonical.com