[arch-general] kernel26 in [current] cries for love when new kernel version hits [testing]
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.
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...
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
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. 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
On Tue, 2009-12-15 at 14:51 +0700, Emmanuel Benisty wrote:
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
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. 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]).
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. 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?
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
On Tue, 2009-12-15 at 14:51 +0700, Emmanuel Benisty wrote:
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
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)
On Tue, Dec 15, 2009 at 7:58 AM, Emmanuel Benisty <benisty.e@gmail.com> wrote:
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)
And that is why the .32 kernel is not in [core] yet. As I understand it, the kernel packaging process shouldn't take long, but sometimes bugs pop in and they don't always have a solution quick enough. In this case, .31.8 was released by kernel.org before .32 was stable in Arch. But it's just an exception, not the rule. I've seen kernels being released in [core] fast enough. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Tue, 2009-12-15 at 16:58 +0700, Emmanuel Benisty wrote:
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
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. Of course, if there's a very pressing bug that requires the latest 2.6.31 in every Arch machine within this 1-month period, it would be a different scenario, and I'm sure the devs/TUs would see that as well.
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
On Tue, 2009-12-15 at 16:58 +0700, Emmanuel Benisty wrote:
2009/12/15 Ng Oon-Ee <ngoonee@gmail.com>:
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.
On Tue, Dec 15, 2009 at 11:26 AM, Emmanuel Benisty <benisty.e@gmail.com> wrote:
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.
So better file a feature request.
On Tue, 2009-12-15 at 11:38 +0100, Xavier wrote:
On Tue, Dec 15, 2009 at 11:26 AM, Emmanuel Benisty <benisty.e@gmail.com> wrote:
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.
So better file a feature request.
@Emmanuel: Obviously we disagree on whether this is 'the way to go'. The feature request is a good idea, however, and I do believe you have a pretty good chance of getting it accepted if a proper plan is presented.
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
Unless I'm mistaken you're talking about something like the closed source nVidia drivers, correct? If what you're looking for in the -lts kernel is long time support on a stable kernel, then I doubt you'll be using any out of kernel modules (closed source video drivers on a server?). All other drivers/modules should have support for their latest versions back-ported to this kernel, no?
This whole "use kernel26-lts" thing, in this case, is a non-sense
anyway... and using unsupported packages is _definitely_ not an option.
This isn't really the point of kernel26-lts as the devs envisioned it. Kernel26-lts, for most people, is really just a fallback in the case that a new kernel install messes up, so you don't have to work some magic with an install image (or reinstall complete if you don't know how/have the patience). Unless I'm mistaken you're talking about something like the closed source nVidia drivers, correct? If what you're looking for in the -lts kernel is long time support on a stable kernel, then I doubt you'll be using any out of kernel modules.
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.
While it would be a good approach, and desirable, it would not be feasible to execute it without restructuring the repositories in some manner. I'm almost certain that every kernel update (no matter how small) spends time in [testing] to ensure that there are no huge, unsightly errors. With kernel26-2.6.32 in [testing] right now even if you put kernel26-2.6.31.8 in there it wouldn't install on anyone's machine as the new package would take precedence. Unless the devs made some staging repo where they could all sign off on the incremental updates of the last version of the kernel, then it wouldn't be possible. If they did do this it would spread the users of [testing] thin. There are already enough issues with so few testers/bug reporters that I think we can all agree this would not be desirable.
participants (5)
-
Christopher Daley
-
Denis A. Altoé Falqueto
-
Emmanuel Benisty
-
Ng Oon-Ee
-
Xavier