[aur-general] LTS kernel moved to 3.10.x - module rebuilds

[Pedro Alejandro López-Valencia]

On Mon, Sep 16, 2013 at 8:59 PM, Brian F. G. Bidulock
<bidulock at 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.

-- 
http://about.me/palopezv