RFC: Stable kernel updates and the SRU process

[Pete Graner]

Stefan Bader wrote:
> Martin Pitt wrote:
>> Stefan Bader [2008-10-28 12:44 -0400]:
>>> Still I think it would be better to revert selectively if there are regressions
>>> found than only to select a few patches and miss fixes until we get bitten by them.
>> That's not actually that preferable. It's generally better to keep
>> known bugs which people got used to than breaking something that
>> worked before (which is generally a disaster in critical environments,
>> whereas bugs which have been there forever are merely an
>> inconvenience). That obviously doesn't apply to things like the recent
>> e1000 NVRAM incident, but for most severity "normal" bugs.
>>
>> Martin
>>
> 
> This definitely should be accompanied by a wider or longer testing period. I
> fully agree with that. My feeling would be that changes to the upstream stable
> kernel are pretty well like SRUs in the way that they normally fix something to
> get included. I don't have numbers regarding how many times the kernel broke
> because of a stable patch. To minimize the risk there we could delay the import
> of the next stable patchset a few weeks as well as enlarge the time an update
> has to remain in -proposed.
> 
> 

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


~pete

-- 
Pete Graner	<pgraner at canonical.com>