On Wed, 2010-08-11 at 19:39 -0700, Jeff Carr wrote: > On Tue, Aug 10, 2010 at 19:21, Ben Hutchings <ben@decadent.org.uk> wrote: > > > Why is that necessary when they are available in experimental? > > It's a problem for me because I deal with lots of people that I can't > explain that too. > > > Bear in mind that we do not want to have multiple kernel versions in one > > release, as that increases the support burden. > > Interesting. Perhaps that can be revisited? I don't know the history > of what was a PITA in the past so I totally understand if I'm > misunderstanding the scope. Either way there is some sort of support > burden: on one hand you have more than one kernel (support problems), > on the other hand, you don't have newer kernels (other problems). The kernel team (in conjunction with the security team) decided that one kernel per release is less trouble. There was an experiment with adding a later kernel version to the etch release, but I don't think the results were that positive. For lenny and squeeze we have instead backported new hardware support. > In general, I think it's a valid argument to view the kernel as > similar to gcc. Just like there is software that will only build with > a specific version of gcc, there are new machines that will not run on > old kernels. No, this is a different situation: I cannot pick and choose which kernels to run to support different devices in the same machine! (Actually, that is not quite true. A hypervisor supported by an IOMMU can allow different guest kernels to handle different devices. But this is hardly convenient!) > And, like gcc, there are several core packages that have > multiple versions available for various reasons: automake, readline, > python, etc. > > > Please file a bug on the kernel version in 'sid' for each unsupported > > The problems I've seen I didn't think were bugs because the 2.6.35 > packages you made work. So in that regard -- thanks for your packages > because they work! > > It didn't occur to me to report back porting bugs. Anyway, it would > have been a waste of time for everyone. I respect your enthusiasm, but > I don't have time to make backported patches. We don't expect you to do that. Just tell us what's missing. > That's very difficult, > time consuming and sometimes not safe anyway. Forward looking problems > like why video breaks in 2.6.35 (Lenovo T61p) are more important to > me. > > I'm just trying to humbly suggest (or lobby) for the inclusion of > 2.6.34, 2.6.35,etc. directly in sid. This might benefit kernel > development in general. Lots of users are aware of apt-cache search & > would try them on a wider array of machines. Particularly in sid where > users are a bit more savvy. Sorry, this is not going to happen. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part