From: Scott Branden <firstname.lastname@example.org> To: Willy Tarreau <email@example.com> Cc: Greg Kroah-Hartman <firstname.lastname@example.org>, Sasha Levin <email@example.com>, Florian Fainelli <firstname.lastname@example.org>, BCM Kernel Feedback <email@example.com>, LKML <firstname.lastname@example.org>, Linux ARM <email@example.com> Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Date: Thu, 18 Feb 2021 14:38:42 -0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20210218210037.GA16034@1wt.eu> [-- Attachment #1: Type: text/plain, Size: 4383 bytes --] Hi Willy, On 2021-02-18 1:00 p.m., Willy Tarreau wrote: > 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 - will forward such info as necessary. > > Thanks, > Willy > [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4169 bytes --]
next prev parent reply other threads:[~2021-02-18 22:39 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-25 19:55 Scott Branden 2021-01-26 2:50 ` Adam Borowski 2021-01-26 7:29 ` Greg Kroah-Hartman 2021-01-26 17:35 ` Florian Fainelli 2021-01-26 18:30 ` Scott Branden 2021-01-26 18:51 ` Greg Kroah-Hartman 2021-01-26 20:15 ` Willy Tarreau 2021-02-17 9:40 ` Greg Kroah-Hartman 2021-02-17 19:48 ` Scott Branden 2021-02-18 7:43 ` Greg Kroah-Hartman 2021-02-18 11:31 ` Willy Tarreau 2021-02-18 14:15 ` Jari Ruusu 2021-02-18 14:29 ` Greg Kroah-Hartman 2021-02-18 20:55 ` Pavel Machek 2021-02-18 22:43 ` Ondrej Zary 2021-02-19 8:00 ` Pavel Machek 2021-02-19 8:30 ` Greg Kroah-Hartman 2021-02-18 14:33 ` Willy Tarreau 2021-02-18 17:19 ` Jari Ruusu 2021-02-18 17:22 ` Russell King - ARM Linux admin 2021-02-18 17:44 ` Greg Kroah-Hartman 2021-02-19 7:10 ` Jari Ruusu 2021-02-19 8:22 ` Greg Kroah-Hartman 2021-02-19 10:31 ` Jari Ruusu 2021-02-19 10:37 ` Greg Kroah-Hartman 2021-02-19 10:57 ` Jari Ruusu 2021-02-19 11:16 ` Greg Kroah-Hartman 2021-02-19 15:23 ` Jari Ruusu 2021-02-20 13:29 ` Jari Ruusu 2021-02-20 16:05 ` Greg Kroah-Hartman 2021-02-20 17:06 ` Willy Tarreau 2021-02-21 11:38 ` Jari Ruusu 2021-02-19 16:50 ` Theodore Ts'o 2021-02-18 17:16 ` Florian Fainelli 2021-02-18 12:51 ` Pavel Machek 2021-02-18 16:51 ` Sasha Levin 2021-02-18 17:21 ` Florian Fainelli 2021-02-18 17:53 ` Greg Kroah-Hartman 2021-02-18 17:57 ` Florian Fainelli 2021-02-18 18:20 ` Willy Tarreau 2021-02-18 18:36 ` Greg Kroah-Hartman 2021-02-18 20:16 ` Scott Branden 2021-02-18 21:00 ` Willy Tarreau 2021-02-18 22:38 ` Scott Branden [this message] 2021-02-18 21:39 ` Sasha Levin 2021-02-18 22:00 ` Florian Fainelli 2021-02-18 22:26 ` Scott Branden 2021-02-19 8:25 ` Greg Kroah-Hartman 2021-02-19 15:05 ` Florian Fainelli 2021-02-19 15:53 ` Greg Kroah-Hartman 2021-02-19 17:44 ` Florian Fainelli 2021-02-22 14:17 ` Greg Kroah-Hartman 2021-02-18 17:42 ` Florian Fainelli 2021-02-18 18:13 ` Willy Tarreau 2021-02-18 10:04 ` Pavel Machek 2021-02-19 8:54 ` Hanjun Guo 2021-02-19 9:08 ` Greg Kroah-Hartman 2021-02-20 7:02 ` Hanjun Guo 2021-02-20 9:53 ` Greg Kroah-Hartman 2021-02-23 2:14 ` Hanjun Guo 2021-02-19 14:45 ` Nikolai Kondrashov 2021-02-26 8:03 ` Hanjun Guo 2021-02-26 11:21 ` Nikolai Kondrashov 2021-02-22 14:00 ` Nishanth Aravamudan 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: 5.10 LTS Kernel: 2 or 6 years?' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).