[arch-general] kernel26 in [current] cries for love when new kernel version hits [testing]

[Ng Oon-Ee]

On Tue, 2009-12-15 at 16:58 +0700, Emmanuel Benisty wrote:
> 2009/12/15 Ng Oon-Ee <ngoonee at 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.