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

[Christopher Daley]

>
> >> >> 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.