2009/12/15 Ng Oon-Ee <ngoonee@xxxxxxxxx>: > On Tue, 2009-12-15 at 16:58 +0700, Emmanuel Benisty wrote: >> 2009/12/15 Ng Oon-Ee <ngoonee@xxxxxxxxx>: >> > 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? > > Other packages are simpler in that once they move on from 1.1.1 to 1.2.1 > there is no 1.1.2 coming. Samba being the other exception I know of, > besides the kernel. > > I'd consider the dev's computer time pretty valuable, myself. Very easy > to suggest that someone else spend time, and it WOULD have a point if > the package wasn't a dead-end branch. > >> > 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]. > > I don't recall any sort of 'maximum time' a package is allowed to be > out-of-date. I can certainly recall some packages I use being a month or > so out of date, simply due to the dev/TU in charge not having the time. > With infinite time I'm sure this would be doable, but obviously we don't > live in that world. > >> >> 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. > > It's not? Why not? You use Arch, I'm sure you'd know how to check it for > obvious problems. In this case, its even simpler cos all you have to do > is diff against the PKGBUILD in abs, since its basically the same > package most of the time. > >> > 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) > > You CAN solve the problem. Use [testing], let your system hit the bugs > (if any, I haven't seen any yet), report it, and get kernel26-2.6.32 out > into [core[ a bit faster. > > > There's this undercurrent of "Arch is obliged to provide the latest > software" in your post. I like the latest software as well, but someone > is spending his own personal time on the software I'm using. In a > trivial case like this (in my opinion), then its not worth that > someone's time to satisfy my need for the latest. Funny thing is, as stated in my first post, I'm using Arch stock kernel on only 1 machine out of 4. All of them using [testing] by the way. I'm not the bad guy saying Arch is obliged to do this or that, I just noticed this to be a quite common situation and I still do not think it's the way to go. I do not think Tobias or Thomas will be influenced by this (they may never ever read this thread actually :P ) but that doesn't stop me to voice my opinion on this matter. tl;dr: I'm not even complaining as I don't even use those kernels, just saying what I think would be a better approach.
