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.
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
