From: Sasha Levin <sashal@kernel.org>
To: Scott Branden <scott.branden@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: 5.10 LTS Kernel: 2 or 6 years?
Date: Thu, 18 Feb 2021 11:51:04 -0500 [thread overview]
Message-ID: <20210218165104.GC2013@sasha-vm> (raw)
In-Reply-To: <c731b65a-e118-9d37-79d1-d0face334fc4@broadcom.com>
On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote:
>On 2021-02-17 1:40 a.m., Greg Kroah-Hartman wrote:
>> 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).
>And customers are finicky and ask for one thing and then change their mind later.
Why would we commit to maintining an upstream LTS for 6 years then? If
no one ends up using it (and we don't want anyone using older LTS
kernels) we're still stuck maintaining it.
>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
This sounds very wrong: it's ok to get volunteers to commit to 6 years
while the company that is asking for it won't do the same?
Shouldn't Broadcom commit to the work involved here first?
>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.
Keep in mind that QA resources are generally more abundant than
engineering resources that need to actually backport stuff to old
kernels.
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: Scott Branden <scott.branden@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: 5.10 LTS Kernel: 2 or 6 years?
Date: Thu, 18 Feb 2021 11:51:04 -0500 [thread overview]
Message-ID: <20210218165104.GC2013@sasha-vm> (raw)
In-Reply-To: <c731b65a-e118-9d37-79d1-d0face334fc4@broadcom.com>
On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote:
>On 2021-02-17 1:40 a.m., Greg Kroah-Hartman wrote:
>> 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).
>And customers are finicky and ask for one thing and then change their mind later.
Why would we commit to maintining an upstream LTS for 6 years then? If
no one ends up using it (and we don't want anyone using older LTS
kernels) we're still stuck maintaining it.
>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
This sounds very wrong: it's ok to get volunteers to commit to 6 years
while the company that is asking for it won't do the same?
Shouldn't Broadcom commit to the work involved here first?
>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.
Keep in mind that QA resources are generally more abundant than
engineering resources that need to actually backport stuff to old
kernels.
--
Thanks,
Sasha
next prev parent reply other threads:[~2021-02-18 16:52 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 19:55 5.10 LTS Kernel: 2 or 6 years? Scott Branden
2021-01-25 19:55 ` Scott Branden
2021-01-26 2:50 ` Adam Borowski
2021-01-26 2:50 ` Adam Borowski
2021-01-26 7:29 ` Greg Kroah-Hartman
2021-01-26 7:29 ` Greg Kroah-Hartman
2021-01-26 17:35 ` Florian Fainelli
2021-01-26 17:35 ` Florian Fainelli
2021-01-26 18:30 ` Scott Branden
2021-01-26 18:30 ` Scott Branden
2021-01-26 18:51 ` Greg Kroah-Hartman
2021-01-26 18:51 ` Greg Kroah-Hartman
2021-01-26 20:15 ` Willy Tarreau
2021-01-26 20:15 ` Willy Tarreau
2021-01-29 10:00 ` 10 years -- was " Pavel Machek
2021-02-17 9:40 ` Greg Kroah-Hartman
2021-02-17 9:40 ` Greg Kroah-Hartman
2021-02-17 19:48 ` Scott Branden
2021-02-17 19:48 ` Scott Branden
2021-02-18 7:43 ` Greg Kroah-Hartman
2021-02-18 7:43 ` Greg Kroah-Hartman
2021-02-18 11:31 ` Willy Tarreau
2021-02-18 11:31 ` Willy Tarreau
2021-02-18 14:15 ` Jari Ruusu
2021-02-18 14:15 ` Jari Ruusu
2021-02-18 14:29 ` Greg Kroah-Hartman
2021-02-18 14:29 ` Greg Kroah-Hartman
2021-02-18 20:55 ` Pavel Machek
2021-02-18 20:55 ` Pavel Machek
2021-02-18 22:43 ` Ondrej Zary
2021-02-18 22:43 ` Ondrej Zary
2021-02-19 8:00 ` Pavel Machek
2021-02-19 8:00 ` Pavel Machek
2021-02-19 8:30 ` Greg Kroah-Hartman
2021-02-19 8:30 ` Greg Kroah-Hartman
2021-02-18 14:33 ` Willy Tarreau
2021-02-18 14:33 ` Willy Tarreau
2021-02-18 17:19 ` Jari Ruusu
2021-02-18 17:19 ` Jari Ruusu
2021-02-18 17:22 ` Russell King - ARM Linux admin
2021-02-18 17:22 ` Russell King - ARM Linux admin
2021-02-18 17:44 ` Greg Kroah-Hartman
2021-02-18 17:44 ` Greg Kroah-Hartman
2021-02-19 7:10 ` Jari Ruusu
2021-02-19 7:10 ` Jari Ruusu
2021-02-19 8:22 ` Greg Kroah-Hartman
2021-02-19 8:22 ` Greg Kroah-Hartman
2021-02-19 10:31 ` Jari Ruusu
2021-02-19 10:31 ` Jari Ruusu
2021-02-19 10:37 ` Greg Kroah-Hartman
2021-02-19 10:37 ` Greg Kroah-Hartman
2021-02-19 10:57 ` Jari Ruusu
2021-02-19 10:57 ` Jari Ruusu
2021-02-19 11:16 ` Greg Kroah-Hartman
2021-02-19 11:16 ` Greg Kroah-Hartman
2021-02-19 15:23 ` Jari Ruusu
2021-02-19 15:23 ` Jari Ruusu
2021-02-20 13:29 ` Jari Ruusu
2021-02-20 13:29 ` Jari Ruusu
2021-02-20 16:05 ` Greg Kroah-Hartman
2021-02-20 16:05 ` Greg Kroah-Hartman
2021-02-20 17:06 ` Willy Tarreau
2021-02-20 17:06 ` Willy Tarreau
2021-02-21 11:38 ` Jari Ruusu
2021-02-21 11:38 ` Jari Ruusu
2021-02-19 16:50 ` Theodore Ts'o
2021-02-19 16:50 ` Theodore Ts'o
2021-02-18 17:16 ` Florian Fainelli
2021-02-18 17:16 ` Florian Fainelli
2021-02-18 12:51 ` Pavel Machek
2021-02-18 12:51 ` Pavel Machek
2021-02-18 16:51 ` Sasha Levin [this message]
2021-02-18 16:51 ` Sasha Levin
2021-02-18 17:21 ` Florian Fainelli
2021-02-18 17:21 ` Florian Fainelli
2021-02-18 17:53 ` Greg Kroah-Hartman
2021-02-18 17:53 ` Greg Kroah-Hartman
2021-02-18 17:57 ` Florian Fainelli
2021-02-18 17:57 ` Florian Fainelli
2021-02-18 18:20 ` Willy Tarreau
2021-02-18 18:20 ` Willy Tarreau
2021-02-18 18:36 ` Greg Kroah-Hartman
2021-02-18 18:36 ` Greg Kroah-Hartman
2021-02-18 20:16 ` Scott Branden
2021-02-18 20:16 ` Scott Branden
2021-02-18 21:00 ` Willy Tarreau
2021-02-18 21:00 ` Willy Tarreau
2021-02-18 22:38 ` Scott Branden
2021-02-18 22:38 ` Scott Branden
2021-02-18 21:39 ` Sasha Levin
2021-02-18 21:39 ` Sasha Levin
2021-02-18 22:00 ` Florian Fainelli
2021-02-18 22:00 ` Florian Fainelli
2021-02-18 22:26 ` Scott Branden
2021-02-18 22:26 ` Scott Branden
2021-02-19 8:25 ` Greg Kroah-Hartman
2021-02-19 8:25 ` Greg Kroah-Hartman
2021-02-19 15:05 ` Florian Fainelli
2021-02-19 15:05 ` Florian Fainelli
2021-02-19 15:53 ` Greg Kroah-Hartman
2021-02-19 15:53 ` Greg Kroah-Hartman
2021-02-19 17:44 ` Florian Fainelli
2021-02-19 17:44 ` Florian Fainelli
2021-02-22 14:17 ` Greg Kroah-Hartman
2021-02-22 14:17 ` Greg Kroah-Hartman
2021-02-18 17:42 ` Florian Fainelli
2021-02-18 17:42 ` Florian Fainelli
2021-02-18 18:13 ` Willy Tarreau
2021-02-18 18:13 ` Willy Tarreau
2021-02-18 10:04 ` Pavel Machek
2021-02-18 10:04 ` Pavel Machek
2021-01-29 9:49 ` Pavel Machek
2021-02-19 8:54 ` Hanjun Guo
2021-02-19 8:54 ` Hanjun Guo
2021-02-19 9:08 ` Greg Kroah-Hartman
2021-02-19 9:08 ` Greg Kroah-Hartman
2021-02-20 7:02 ` Hanjun Guo
2021-02-20 7:02 ` Hanjun Guo
2021-02-20 9:53 ` Greg Kroah-Hartman
2021-02-20 9:53 ` Greg Kroah-Hartman
2021-02-23 2:14 ` Hanjun Guo
2021-02-23 2:14 ` Hanjun Guo
2021-02-19 14:45 ` Nikolai Kondrashov
2021-02-19 14:45 ` Nikolai Kondrashov
2021-02-26 8:03 ` Hanjun Guo
2021-02-26 8:03 ` Hanjun Guo
2021-02-26 8:03 ` Hanjun Guo
2021-02-26 11:21 ` Nikolai Kondrashov
2021-02-26 11:21 ` Nikolai Kondrashov
2021-02-22 14:00 ` Nishanth Aravamudan
2021-02-22 14:00 ` Nishanth Aravamudan
2021-02-22 14:24 ` Greg Kroah-Hartman
2021-02-22 14:24 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210218165104.GC2013@sasha-vm \
--to=sashal@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scott.branden@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.