RFC: Stable kernel updates and the SRU process (conclusion)

[Tim Gardner]

Martin Pitt wrote:
>> The one concept that I failed to mention in the original RFC is that of
>> forcing an ABI bump for these updates. None of the patches in
>> v2.6.27.3-v2.6.27.4 require an ABI bump. However, in the event that one
>> of these patches _does_ cause a regression, I think it is important to
>> be able to fall back to a previously installed kernel.
> 
> last-known-good-boot would be so much better for this.. I guess we'll
> get it in Jaunty?
> 

In the meantime, I did upload linux_2.6.27-8.17 last night. Note the ABI
bump.

> Otherwise I really truly dislike ABI bumps in stables. We sort of got
> (too much) used to them, but they are a real pain for everyone who
> uses a third-party module. It doesn't just affect partners, but also
> drivers which users install themselves, without being packaged
> properly. This constantly breaks whatever for them.
> 

I am unsympathetic. Third party modules developers have had 3 choices
during the Intrepid development cycle; 1) Get their module upstream, 2)
Get their module in the Ubuntu kernel package, 3) Use an external build
mechanism like DKMS.

> TBH I'd rather have it mature in -proposed for long enough that we can
> be reasonably sure to not totally break booting for everyone.
> 

In that regard, i.e., totally break booting for everyone, I typically
load a new kernel on 8 laptops and 4-6 desktops in order to make sure it
at least boots. Then I make sure that there haven't been any silly
regressions like graphics, suspend/resume, and some short load tests.

>> [1] The idea has been put forth that kernels be moved into -updates at
>> fixed times, perhaps on a quarterly basis, a change from the current
>> policy of 7 days testing in -proposed. Of course, there will have to be
>> a freeze period before being released.
> 
> I think there are two classes we have to consider here:
> 
>  * Urgent regressions and really bad bugs, which use to come up right
>    after a release. For those, the standard 7 day/minimal patches
>    approach still sounds right to me.
> 
>  * After a release is out for a couple of months, such as dapper and
>    hardy, switching over to 2 or 4 kernel updates per year to fix
>    hardware and non-urgent bugs sounds appropriate.
> 

Agreed. Urgent regressions and really bad bugs always create their own
circumstances.

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