Re: 5.10 LTS Kernel: 2 or 6 years?

On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote:

Hi Greg,

On 2021-02-17 1:40 a.m., Greg Kroah-Hartman wrote:

quoted

On Tue, Jan 26, 2021 at 07:51:18PM +0100, Greg Kroah-Hartman wrote:

quoted

On Tue, Jan 26, 2021 at 10:30:16AM -0800, Scott Branden wrote:

quoted

Hi Greg,


On 2021-01-25 11:29 p.m., Greg Kroah-Hartman wrote:

quoted

On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote:

quoted

Hi All,

The 5.10 LTS kernel being officially LTS supported for 2 years presents a problem:
why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has a 6 year LTS.

Because they want to use all of the latest stuff that 5.10 provides
them.  Don't you want faster and more secure kernels for your devices?

Yes, 5.10 is a more secure and less buggy kernel than 5.4.

Great, use it, ship it to your customers and we are all happy.  What do
you need me for any of this?  :)

quoted

quoted

quoted

  And AOSP has already declared the use
of 5.10 kernel in their Android S and T releases.

Publically?  Where?  And is that really the name of the new Android
releases, I thought they switched to numbers now (hence the naming of
the current android-common kernel branches, marketing is fun...)

https://source.android.com/devices/architecture/kernel/android-common
Feature and launch kernels provides kernels supported per version.

Oh nice, didn't know that.

But note, Android kernels do not reflect the lifespan of LTS kernels.
If that were the case, I would still be supporting 3.18 as they are
doing that at the moment for their devices and customers, and will be
doing so for I think another full year.

So while Android is nice to see here, remember that is what Google is
promising to support for their users.  You can do the same thing for
your users, what do you need me here for this?  You can do the same
thing that Google is doing for 3.18 right now, pick the stable fixes
from upstream, backport them, test them, and push them out to their
users.

While Google is a great help to me in the LTS effort, providing huge
amounts of resources to enable my life easier with this (i.e. funding
Linaro's testing efforts), their promise to their customers/users does
not depend on me keeping LTS kernels alive, if I stopped tomorrow their
contracts are still in place and they know how to do this work
themselves (as is proof with 3.18).

So you can provide the same kind of guarantee to support any kernel
version for any amount of time to any customer you like, it shouldn't
require me to do that work for you, right?

quoted

quoted

quoted

Is there some way we could make the LTS support more clear.
A 2 year declaration is not LTS any more.

Not true at all, a "normal" stable kernel is dropped after the next
release happens, making their lifespan about 4 months long.  2 years is
much longer than 4 months, so it still is a "long term supported" kernel
in contrast, correct?

Perhaps a new name needs to be made for "LTS" for 6 years to distinguish it from 2 years.
The timeframes are very different.

At this point in time, anyone wanting a kernel longer than 2 years
should know how this all works.

If not, please do some basic research, I have written whitepapers on
this and given numerous talks.  The information is out there...

quoted

quoted

quoted

If 5.10 is "actually" going to be supported for 6 years it would be quite valuable to make such a declaration.
https://www.kernel.org/category/releases.html

Why?  What would that change?

Ok, seriously, this happens every year, and every year we go through the
same thing, it's not like this is somehow new, right?

No, but why do we need to keep playing the same game every year now.

Because, 5.4 almost did not become "6 years" of support from me.  That
was because in the beginning, no one said they were going to use it in
their devices and offer me help in testing and backporting.  Only when I
knew for sure that we had people helping this out did I change the date
on kernel.org.

So far the jury is still out for 5.10, are you willing to help with
this?  If not, why are you willing to hope that others are going to do
your work for you?  I am talking to some companies, but am not willing
to commit to anything in public just yet, because no one has committed
to me yet.

Following up on this as I did not hear back from you.  Are you and/or
your company willing to help out with the testing of 5.10 to ensure that
it is a LTS kernel?  So far I have not had any companies agree to help
out with this effort, which is sad to see as it seems that companies
want 6 years of stable kernels, yet do not seem to be able to at the
least, do a test-build/run of those kernels, which is quite odd...

I personally cannot commit to supporting this kernel for 6 years
(and personally do not want to backport new features to a 6 year old kernel).

Why would you backport new features to an old kernel?  That's not what
they are there for.

And customers are finicky and ask for one thing and then change their mind later.

Sure, but it's up to you to define what you will support, for your
customers, which is what I am asking here.

We'll have to see what decisions are made at a company level for this as there
are added costs to run tests on LTS kernel branches.  We already run extensive QA on
whatever active development branches are in use and a subset on the mainline
branch as well.  QA resources are finite and committing those for 6 years is
not something that makes sense if customers drop that kernel version.
Testing of the LTS kernel changes really moves out of our hands and into the
customer's testing after our major releases to them.

That feels wrong, but hey, I'm not your customer.  If I was, I would be
demanding all LTS updates for the specific kernel branch you gave me as
I am paying for that support :)

Other difficulty with the LTS version is the frequency it is updated.  We would not
pickup the changes that frequently to test.  A quarterly, bi-annually, or when a critical fix
is identified would be when we update and perform any meaningful testing when in maintainence.

How are you "identifying" these "critical fixes"?  We fix at least one
known security issue a week, and probably multitudes of
unknown-at-this-moment ones.  How are you determining when you need to
send a new base kernel update off to your customers?  At such long
intervals it feels like anyone using your kernel releases is woefully
insecure.

Although if you do get people to update on a quarterly basis no matter
what, that's better than nothing, I'll take that.  What's the odds that
this really happens?

quoted

If you want to point people at your company this link that explains it
all in a single location instead of an email thread:
	http://www.kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/
that would be great.

Thanks for the link.  Will forward it to see if it helps make any commitment from customers
or company.

Thanks.  When can I expect to hear something back, even if it is a "no,
we don't care about supporting 5.10"?

The link Pavel sent looks interesting.
"CIP project intends to maintain 5.10 for a long time, so you can expect testing/help from them:
https://www.cip-project.org/blog/2020/12/02/cip-to-embark-on-kernel-5-10-development-for-slts
"

If the CIP project has committed to 10 years you would think they would be in contact
with you to add their support to the 5.10 LTS effort.

They are doing testing right now, see the announcements where they test
each stable -rc release.  But they have not talked to me about 5.10
yet, Their model is that they will, somehow in a way that is yet to be
determined, take over maintaining these releases _after_ I drop them.
But they are only going to do so for a very specific hardware platform
or two, so anyone using anything other than their specific boards, is
going to be out of luck.

Which makes sense, scoping support like this to those that actually care
about a specific hardware platform is much easier than the work that I
and Sasha do in support it for all platforms.  So if you are interested
in 10 years, please work with CIP to get your platform into that list.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel