Hi, I'd like to start a discussion on the ins and outs of getting newer kernels into stable. This is provoked by Chris' email, msgid <[🔎] 20040329002543.GP9248@cheney.cx> I realise there are issues with adding and removing kernels into stable, as the security maintenance goes up, and I'd like to hear what the security team has to say about that. Or perhaps newer kernels should go into stable-proposed-updates? This doesn't really address the installation issues that people have with newer hardware though. Is it feasable for subsequent point releases of stable to ship with newer kernels by default, and security support for earlier kernels to be discontinued at point release time? for example, let's say hypothetically, Sarge shipped with 2.6.4, and then 3 months later, Sarge_r1 ships with 2.6.6 as the default kernel, and a month later, a vulnerability is found in 2.6.4, that isn't in 2.6.6. Would we need to issue a patched 2.6.4 if we were already providing a non-vulnerable 2.6.6 in a newer point release of stable? I think the kernel is probably the single biggest package that really dates a stable release (sure, there's lots of other "perishable" packages like spamassassin and snort, for example), but if you can't install the stable release because the kernel it uses can't find your hardware, then you're really behind the eightball from the word go. Joey, as SRM, what do you think? Is the installability of stable releases on modern hardware something you think is significant? Is there some sort of compromise that can be arrived at for the handling of newer kernels in stable? regards Andrew
Attachment:
signature.asc
Description: Digital signature