[elrepo] 4.14 LTS

Robin P. Blanchard robin.blanchard at gmail.com
Thu Sep 6 13:43:05 EDT 2018


Given that GHK is extending support for LTS kernels to six years, what
will the landscape of ELREPO look like? eg

4.4 LTS
4.9 LTS
4.14 LTS
4.19 LTS


On Wed, Feb 14, 2018 at 2:12 PM Phil Perry <phil at elrepo.org> wrote:
>
> On 14/02/18 16:54, David Ranch wrote:
> >
> > This is an interesting point.
> >
> > I'd argue that in many respects, the ElRepo group is one of the primary
> > reasons I've stayed on with Centos as it gives me newer kernels than
> > what Redhat/Centos will.  Packages is an entirely different discussion
> > and I digress.  Understanding all that, the 4.4.x kernels are already
> > quite old.  I don't have a good understanding of all the work that goes
> > on behind the scenes for the ElRepo team to release new LT and ML
> > packages but would it be possible to add more LT kernels?  Maybe not all
> > three of them but maybe 4.4 (for the conservative people), 4.14 (for the
> > people who need a long life yet want a mostly modern kernel, and then
> > the ML line for the bleeding edge users?  I know this becomes more and
> > more additive over the years but maybe a little more can be done to keep
> > Centos up to date?
> >
> > --David
> >
>
> Alan is the only one able to give a definitive answer on this, as he is
> the one who does all the hard work, but seeing the amount of work it
> takes to maintain two package sets over 2 distros (was 3 until el5 was
> recently retired, and will be 3 again once el8 is released), and
> multiple arch's, I'd say it's very unlikely.
>
> I'd also question the rationale. kernel-ml is the cutting edge offering,
> and kernel-lt is the LTS offering based upon what is available at the
> time and has LTS support. A key attribute of Enterprise Linux/LTS is we
> provide version stability; we do not change it unless we absolutely have
> to. That is a fundamental cornerstone of the concept of Enterprise Linux.
>
> I appreciate kernel-lt-4.4 may be starting to look long in the tooth in
> some areas, but that is inevitable with any LTS kernel. Interestingly,
> there will reach a point where what started out in life being a newer
> offering (kernel-lt vs the distro kernel) will actually end up reverting
> to the complete opposite. For example, consider wifi support and the
> wifi stack. The EL7 distro kernel started life as 3.10. The wifi stack
> has undergone various backported updates through 3.16 in el7.1, 4.1 in
> el7.2, 4.7 in el7.3, 4.11 in el7.4 and most recently 4.14 in the
> el7.5(beta) kernel, so we see in this respect the distro kernel actually
> becomes 'newer' than kernel-lt by the el7.3 release. This will no doubt
> be happening in other areas as well, so I would fully expect some
> kernel-lt users to revert to using the distro kernel again as time passes.
>
> By the time kernel-4.4 is out of LTS, a successor will be chosen to
> replace it based upon what is available and most suitable at the time,
> and will hopefully see out the 10 year life of the distro. Also, I
> consider kernel-4.14 a poor choice for LTS at present given there is
> only a commitment upstream to support for another 2 years whereas
> kernel-4.4 has a commitment to support for another 4 years.
>
> Ultimately, elrepo aims to offer some extra choice in a convenient
> packaged format where there was none before. Given the amount of work
> Alan puts in to developing and maintaining these packages, I would say
> he is operating at his limit in providing the 2 package sets currently
> available, and given that, I consider the current offerings to be a good
> compromise for the reasons outlined above. That said, if anyone wants to
> maintain a kernel-lt-4.14 offering, they are free to do so given Alan
> has already done a lot of the development work. One could take his last
> kernel-ml-4.14 SRPM, rename to kernel-whatever-4.14 and drop in the
> latest 4.14.x tarball and maintain it for the rest of the 4.14 branch
> life, assuming one has suitable el6/7 build systems and the willingness
> to commit to regularly building a relatively large numbers of kernel
> releases.
>
> In the meantime, if Alan has a differing view, I'm sure he will tell us :-)
>
> Phil
>
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo


More information about the elrepo mailing list