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

[Emmanuel Benisty]

2009/12/15 Ng Oon-Ee <ngoonee at gmail.com>:
> 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.

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.