2009/12/15 Ng Oon-Ee <ngoonee@xxxxxxxxx>: > On Tue, 2009-12-15 at 14:51 +0700, Emmanuel Benisty wrote: >> 2009/12/15 Ng Oon-Ee <ngoonee@xxxxxxxxx>: >> > On Tue, 2009-12-15 at 14:25 +0700, Emmanuel Benisty wrote: >> >> Hi, >> >> >> >> As far as I can remember i.e. quite far but also super blurry, as soon >> >> as a new kernel version hits [testing], the [current] version won't be >> >> updated anymore (it may have happened when _huge_ security issues had >> >> been discovered). Today, we're stuck at .31.6 when .31.8 is out. Not a >> >> complain as I have all the tools to build any kernel I'd like to run >> >> (1 machine running Arch stock kernel out of 4 anyway) but well, just >> >> sayin'... >> >> >> >> Cheers. >> > >> > Well, I personally prefer the devs to focus on the new kernel, since it >> > WILL move to [core] sooner rather than later, invalidating any work done >> > on the earlier kernel. There's also kernel26-lts... >> >> I can't see anything valid here, sorry. "Any work done on the earlier >> kernel" is a simple rebuild and ignoring updates of your most >> important piece of code on your system for weeks is an issue that is >> worth to be raised. If you push this to absurd reasoning then stick >> with 2.6.18 as 2.6.57 will be in [current] also. > > A simple rebuild? At the very least there's the additional efforts of > multiple tests by a variety of devs/TUs, as well as additional > bug-finding/fixing time for bugs brought up by these minor version > updates, the fixing of which may possibly be a waste of time with > regards to the latest kernel. Most of the time, minor versions are _fixing_ bugs, not creating them. Then, no offense to devs but "multiple tests" are often: install>reboot>check dmesg>sign-off. Finally, this is what is done for any package, why should that be different for the linux kernel? > The way I see it, 2.6.32 IS the latest version of kernel26. The fact > that 2.6.31 has more minor updates is mainly for distros which WON'T be > offering 2.6.32, Arch obviously will, and sooner rather than later > (right now, in fact, if you use [testing]). yes 2.6.32 will move to [current] but you can check by yourself, it's NOT there yet. the fact that it will be in a near future is totally not a good reason to keep outdated (branch-wise) packages in [current]. >> In addition, IIRC, there is no out-of-kernel-tree modules for >> kernel26-lts so it's not an option for many users. Anyway, I'm talking >> about updates, not about downgrading few versions of the kernel :P > > I'm sure out-of-kernel-tree modules can be put up in the AUR at the very > least. This whole "use kernel26-lts" thing, in this case, is a non-sense anyway... and using unsupported packages is _definitely_ not an option. > And if we're talking about updates, why not update to the latest > kernel rather than hang around with a new paintjob on an old kernel? yes, that would solve the problem. but that's not the way the kernel update process is designed in Arch. also there are still some blockers ATM (lirc for example)
