[elrepo] 4.14 LTS

[Phil Perry]

On 06/09/18 18:43, Robin P. Blanchard wrote:
> 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
> 
> 

Do you have a reference for that? I've seen the odd indirect mention on 
twitter, but no concrete announcements, but I guess it's driven by SoC 
development timescales?

Our current policy is to provide one LTS kernel (per distro release) and 
stick with it until EOL. Currently, that is the 4.4 LTS branch.

Providing multiple LTS kernels is simply too much work for Alan to 
maintain / cope with hence the decision to only provide a single LTS 
offering. That is very unlikely to change.

As to which LTS kernel that should be - we have taken the decision that 
stability is the most important factor on Enterprise Linux, in much the 
same way Red Hat have. We want to give stability to users to know that 
if they choose to deploy kernel-lt, it isn't going to change tomorrow. 
Hence the decision to stick with the chosen LTS offering until EOL. If 
this isn't what you are looking for and change is what you want then the 
moving target that is kernel-ml might be a better fit.

At present, kernel.org state 4.4 will be supported until Feb, 2022.

Red Hat states RHEL6 will reach EOL on November 30, 2020 so kernel-lt 
will stay at v4.4 until RHEL6 is EOL.

RHEL7 is supported until June 30, 2024, so at some point between 
December 2020 and February 2022 we (meaning the wider "we" including the 
community / users) will have a discussion around choosing a successor to 
kernel-lt on RHEL7 based on what LTS kernels are available at the time, 
their features and suitability and the length of support on offer.

Similar conversations will no doubt occur around the release of RHEL8. 
Based upon past experience, I expect elrepo to initially offer kernel-ml 
and at some point down the line (maybe a year or two) to also introduce 
a kernel-lt offering once sufficient time has elapsed from the original 
distro kernel release (no point picking an LTS kernel too close to the 
distro kernel and then being stuck with it for 4-6 years). If the 
upstream intention is to support LTS offerings for 6 years, then we need 
to make sure we get our decision right when we pick an LTS kernel. It 
might be that the best strategy going forward would be to make sure we 
offer 2 LTS kernels over the supported lifecycle of any RHEL release. 
Maybe no LTS kernel for the first 2 years, and then an LTS offering for 
4 years which is then updated for another 4 years giving a 2-4-4 years 
cycle covering the RHEL 10 year lifespan (hope that makes sense). But 
there will only be one kernel-lt offering at any given time and the 
intention will be for it not to change too frequently (hopefully no more 
than once).

Whilst we are discussing kernels, I should probably mention that 
kernel-ml-4.18.x is likely to be the last mainline release on RHEL6 as 
kernel.org has introduced a build requirement for gcc-4.6 in 
kernel-4.19. As RHEL6 ships with gcc-4.4.7 it will no longer be possible 
to build newer kernel versions on RHEL6. I believe Alan plans to 
continue to maintain kernel-ml-4.18.x on RHEL6 as long as the 4.18 
branch is maintained upstream.