Re: Kernel 2.6.35
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).
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. 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. 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.
--
Jeff
Reply to: