From: Willy Tarreau <w@1wt.eu> To: Scott Branden <scott.branden@broadcom.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sasha Levin <sashal@kernel.org>, Florian Fainelli <f.fainelli@gmail.com>, 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 22:00:37 +0100 [thread overview] Message-ID: <20210218210037.GA16034@1wt.eu> (raw) In-Reply-To: <b283eaa5-028f-a3d0-42a1-5b11c48ffe91@broadcom.com> On Thu, Feb 18, 2021 at 12:16:50PM -0800, Scott Branden wrote: > On 2021-02-18 10:36 a.m., Greg Kroah-Hartman wrote: > > On Thu, Feb 18, 2021 at 07:20:50PM +0100, Willy Tarreau wrote: > >> On Thu, Feb 18, 2021 at 06:53:56PM +0100, Greg Kroah-Hartman wrote: > >>> On Thu, Feb 18, 2021 at 09:21:13AM -0800, Florian Fainelli wrote: > >>>> As a company, we are most likely shooting ourselves in the foot by not > >>>> having a point of coordination with the Linux Foundation and key people > >>>> like you, Greg and other participants in the stable kernel. > >>> > >>> What does the LF have to do with this? > >>> > >>> We are here, on the mailing lists, working with everyone. Just test the > >>> -rc releases we make and let us know if they work or not for you, it's > >>> not a lot of "coordination" needed at all. > >>> > >>> Otherwise, if no one is saying that they are going to need these for 6 > >>> years and are willing to use it in their project (i.e. and test it), > >>> there's no need for us to maintain it for that long, right? > >> > >> Greg, please remember I expressed I really need them for slightly more than > >> 3 years (say 3.5-4) :-) I'm fine with helping a bit more as time permits if > >> this saves me from having to take over these kernels after you, like in the > >> past, but I cannot engage on the regularity of my availability. > > > > Ok, great! > > > > That's one person/company saying they can help out (along with what CIP > > has been stating.) > > > > What about others? Broadcom started this conversation, odd that they > > don't seem to want to help out :) > Greg, I'm sorry but I'm not in a position to provide such a commitment. Are you at least in a position to defend that ? There are necessarily some people in your company who understand the benefits of using open source provdided for free by others and who understand that devoting a few people's time to this task is extremely cheap compared to the amount of work required by having to do it entirely yourself for a lower quality. > My original question arose because the 5.10 kernel is declared as 2 years LTS > while older LTS kernels are now 6 years. (...) > If all LTS kernels were declared as 3.5-4 years as Willy commented this would > solve a few issues. 6 year LTS kernels would only have a maximum 1 year > lifespan over the latest declared LTS kernel. Also, many products take a year > or more to develop, there isn't any life left in an LTS kernel if it is only > 2 years. We all have the same problem regarding this but how do you want Greg to engage into such a task by himself if he's not certain he can count on others to help ? The few of us having worked on extended kernels know that there's a limit around 2.5 years beyond which backports become much harder to perform and to test. Doing it every year would result in 6 LTS kernels to maintain in addition to the last 1-2 stable ones. That becomes a huge amount of work! I even think that having one LTS kernel every 2 years but maintained one extra year (e.g. 5 vs 4 in my case) would reduce the effort. > After 1-3 years of kernel age the relevant parties that want to invest and > care about supporting specific kernel versions longer should become apparent > and could commit to longer support. But that's exactly what's currently being done. Greg initially commits to 2 years hoping to get some help to pursue this longer, and this causes trouble to some of us not being certain upfront whether or not we're choosing the right kernel. So only the solution I'm seeing is for Greg to know early who jumps in so that those of us without the power or skill to entirely maintain a kernel by themselves know early which version to choose. Quite frankly if we ship an LTS kernel in a product, the least we can do is to give back a little bit to make sure the situation remains durable. As such even if you are not in a position to provide such a commitment, I'd appreciate it if you would bring these arguments to those who are in such a position, so that I don't end up as one of the too few ones having to share a significant part of that task to make sure this valuable kernel continues to exist. Thanks, Willy
WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu> To: Scott Branden <scott.branden@broadcom.com> Cc: Sasha Levin <sashal@kernel.org>, Florian Fainelli <f.fainelli@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Thu, 18 Feb 2021 22:00:37 +0100 [thread overview] Message-ID: <20210218210037.GA16034@1wt.eu> (raw) In-Reply-To: <b283eaa5-028f-a3d0-42a1-5b11c48ffe91@broadcom.com> On Thu, Feb 18, 2021 at 12:16:50PM -0800, Scott Branden wrote: > On 2021-02-18 10:36 a.m., Greg Kroah-Hartman wrote: > > On Thu, Feb 18, 2021 at 07:20:50PM +0100, Willy Tarreau wrote: > >> On Thu, Feb 18, 2021 at 06:53:56PM +0100, Greg Kroah-Hartman wrote: > >>> On Thu, Feb 18, 2021 at 09:21:13AM -0800, Florian Fainelli wrote: > >>>> As a company, we are most likely shooting ourselves in the foot by not > >>>> having a point of coordination with the Linux Foundation and key people > >>>> like you, Greg and other participants in the stable kernel. > >>> > >>> What does the LF have to do with this? > >>> > >>> We are here, on the mailing lists, working with everyone. Just test the > >>> -rc releases we make and let us know if they work or not for you, it's > >>> not a lot of "coordination" needed at all. > >>> > >>> Otherwise, if no one is saying that they are going to need these for 6 > >>> years and are willing to use it in their project (i.e. and test it), > >>> there's no need for us to maintain it for that long, right? > >> > >> Greg, please remember I expressed I really need them for slightly more than > >> 3 years (say 3.5-4) :-) I'm fine with helping a bit more as time permits if > >> this saves me from having to take over these kernels after you, like in the > >> past, but I cannot engage on the regularity of my availability. > > > > Ok, great! > > > > That's one person/company saying they can help out (along with what CIP > > has been stating.) > > > > What about others? Broadcom started this conversation, odd that they > > don't seem to want to help out :) > Greg, I'm sorry but I'm not in a position to provide such a commitment. Are you at least in a position to defend that ? There are necessarily some people in your company who understand the benefits of using open source provdided for free by others and who understand that devoting a few people's time to this task is extremely cheap compared to the amount of work required by having to do it entirely yourself for a lower quality. > My original question arose because the 5.10 kernel is declared as 2 years LTS > while older LTS kernels are now 6 years. (...) > If all LTS kernels were declared as 3.5-4 years as Willy commented this would > solve a few issues. 6 year LTS kernels would only have a maximum 1 year > lifespan over the latest declared LTS kernel. Also, many products take a year > or more to develop, there isn't any life left in an LTS kernel if it is only > 2 years. We all have the same problem regarding this but how do you want Greg to engage into such a task by himself if he's not certain he can count on others to help ? The few of us having worked on extended kernels know that there's a limit around 2.5 years beyond which backports become much harder to perform and to test. Doing it every year would result in 6 LTS kernels to maintain in addition to the last 1-2 stable ones. That becomes a huge amount of work! I even think that having one LTS kernel every 2 years but maintained one extra year (e.g. 5 vs 4 in my case) would reduce the effort. > After 1-3 years of kernel age the relevant parties that want to invest and > care about supporting specific kernel versions longer should become apparent > and could commit to longer support. But that's exactly what's currently being done. Greg initially commits to 2 years hoping to get some help to pursue this longer, and this causes trouble to some of us not being certain upfront whether or not we're choosing the right kernel. So only the solution I'm seeing is for Greg to know early who jumps in so that those of us without the power or skill to entirely maintain a kernel by themselves know early which version to choose. Quite frankly if we ship an LTS kernel in a product, the least we can do is to give back a little bit to make sure the situation remains durable. As such even if you are not in a position to provide such a commitment, I'd appreciate it if you would bring these arguments to those who are in such a position, so that I don't end up as one of the too few ones having to share a significant part of that task to make sure this valuable kernel continues to exist. Thanks, Willy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-18 21:01 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 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 [this message] 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=20210218210037.GA16034@1wt.eu \ --to=w@1wt.eu \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=f.fainelli@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=sashal@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: linkBe 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.