Don, On Mon, 16 Sep 2013, Don deJuan wrote:

It was picked for long term support. I think that is why it was the one chosen. http://www.kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/

If you look at https://www.kernel.org/category/releases.html you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x is EOL Sept, 2015. (Obviously 3.0.x is EOL Oct 2013, next month, so some change is necessary.) When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header files needed a minimum kernel above 2.6.34. I was wondering whether there was a similar technical reason for the 3.10.x choice over 3.2.x, or whether I can just as easily run a 3.2.x kernel on an otherwise Plain Jane and current Arch Linux build? --brian

Hi On Tue, Sep 17, 2013 at 5:26 AM, Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:

On Mon, Sep 16, 2013 at 8:59 PM, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

...

If you look at https://www.kernel.org/category/releases.html you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x is EOL Sept, 2015. (Obviously 3.0.x is EOL Oct 2013, next month, so some change is necessary.)

...

When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header files needed a minimum kernel above 2.6.34. I was wondering whether there was a similar technical reason for the 3.10.x choice over 3.2.x, or whether I can just as easily run a 3.2.x kernel on an otherwise Plain Jane and current Arch Linux build?

Off the top of my head, the discussion in arch-dev-public went about two main points: 1:) Arch is a distribution that prides itself in being on the bleeding edge of technology. If there is a new LTS kernel since now and September 2015, be sure it will replace the present version unless there are apocalyptic reasons not to do it. 2.) The 3.10 kernel has much better hardware support and gives access to a lot of newer technology that LTS users might want to use.

On my side, I can see a very important and beneficial side effect of using 3.10 as LTS kernel: It is very well integrated with systemd. In fact it has already part of the work that supports the new hirearchical cgroups world, therefore it will be more compatible with future systemd versions. Furthermore, the technological advance in file-systems, virtualization and graphics support from 3.2 to 3.10 is not something to ignore.

Perhaps I ought to point out that a kernel.org LTS is a bug-fix only affair unless there is an obvious need to correct a glaring mistake, new features are not added lightly. That's not the case with vendor kernels. They choose to add the support and backport the features they want, that is: those kernels are Frankenstein monsters. A RHEL 5 2.6.17 kernel is really made out of the corpses of all kernels up to 3.8 at this time ---taking an educated guess--- and that is without taking into consideration all the out-of-tree additions that are not either in Torvald's nor linux-next trees.

I would suggest to rename linux-lts to linux-lts-3.2 and keep it in the repo for a while. This is the way how Arch can keep old version of the package. So people who does not want to rush with kernel upgrade can use that package. Later (in ~12 months) this package can be removed or moved to AUR.

On Tue, 17 Sep 2013 09:36:44 -0500 Pedro Alejandro López-Valencia <palopezv@gmail.com> wrote:

El mar, 17-09-2013 a las 06:09 -0700, Anatol Pomozov escribió:

...

I would suggest to rename linux-lts to linux-lts-3.2 and keep it in the repo for a while. This is the way how Arch can keep old version of the package.

This sounds reasonable, but see below.

...

So people who does not want to rush with kernel upgrade can use that package. Later (in ~12 months) this package can be removed or moved to AUR.

Considering the maintenance burden on the devs (they are not many and we all are volunteers here), this lts-3.2 could go directly into the AUR. Not that I'm volunteering myself to do it.

In that case don't forget the companion nvidia-lts-3.2, etc packages too... -- Joakim