At Mon, 03 Nov 2014 07:26:33 +0100, Michal Kubecek wrote:
On Friday 31 of October 2014 18:51:35 Atri Bhattacharya wrote:
I can help with that: Kernel 3.17 enables my laptop's (Lenovo Flex 14) touchpad to be recognised while 3.16 doesn't. This is an ALPS v7 device, which got added by way of this commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit /?id=3808843cf10e4a696d942359d99822eff1a2de8e and so missed 3.16.x series. With 13.2, therefore, my touchpad does not work (it is recognised as PS/2 mouse and that is even worse!), but I upgraded to 3.17.1 from Kernel:Stable and it works now. This is not an exotic device either: most recent Lenovo laptops in the Yoga and Flex series come with this or a synaptic touchpad whose support also only got added to Kernel 3.17.
IMHO we should clearly distinguish between maintenance and bugfixes on one side and features and HW enablement on the other.
Right. Meanwhile, we should reconsider why we need to keep the old base kernel. So far, the arguments for keeping 3.16 are: A. It's less work for Jeff B. kABI can be broken by the new kernel (VMware, etc) C. More bugs can be introduced than fixed. Let's begin with A. Here we should replace "Jeff" with general "kernel maintainers". And rethink: is it really less work? With 3.16, we have to backport each patch for the reported security bugs. In the case of stable kernels, it's usually gratis there. For any device bugs (regression, not working, whatever): we report to the upstream, wait resolution there, eventually the upstream fixes in the latest code, tag to Cc to stable. Then finally we can backport it by ourselves. For stable kernels, it's usually gratis there. The kernel base version change is done by HEAD and stable branches, and tested by FACTORY. It's already a regular work. So what would bring "more work" for kernel maintainers by following stable? Now think about B. Yes, this can be a showstopper. However, we don't have to switch to the very newest kernel but stable kernels. Ideally, FACTORY is supposed to be tested more widely than before, so we may catch up the third-party KMPs in time. This needs more evaluation objectively. Finally, about C: of course, this is the biggest question. How is the ratio of fixed vs new bugs? Does anybody have numbers? One thing I'd like to point out is that our position is mostly "just reporting to the upstream and cooperating". And, for upstream, it's even better to be tested with a newer kernel. With an upstream maintainer hat on, I would ask at first to retest with a newer kernel if I get such a bug report. That said, keeping the dead base line is rather more work load for cooperative debugging with upstream. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org