LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Scott Branden <scott.branden@broadcom.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: Tue, 26 Jan 2021 21:15:43 +0100
Message-ID: <20210126201543.GA16044@1wt.eu> (raw)
In-Reply-To: <YBBkplRxzzmPYKC+@kroah.com>

Hi Greg,

On Tue, Jan 26, 2021 at 07:51:18PM +0100, Greg Kroah-Hartman wrote:
> > > 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.

This is interesting, because I used to extend LTS kernels after you dropped
them exactly for the reason I needed them. With 6 months of porting+testing,
~3 years of major version life in field, and roughly 6 extra months covering
late starts or minor extensions to help match a deadline, I figured that 4
years was the minimum we needed for our products. As such, 6 years add some
comfort, but as you probably remember I once got scared not knowing if 4.19
was going to be extended or not as we were having plenty in field and I did
not plan to get back to that maintenance myself. These days, the 6 years
duration allows us to skip one upgrade if we're too late, but we still
prefer to upgrade every year. It's also true that before engaging in that
direction before the official statement was on the site, each time I
preferred to ask you how you felt about it, and I'm sure most major players
decide after checking with you as well. For sure knowing better early would
be much better but I understand your concerns about doing that job for free
and for no reason.

I initially got the impression that the extra resources you got were enough
to help you and to keep me away from annoying you again with pushing my late
branches, but it's certain that free time cannot extend forever. And You,
Ben, Sasha and me definitely know how painful it is to backport past 2.5-3
years, especially with security stuff that everyone expects but often is
the riskiest. While most of my time is spent in userland these days, I'm
still willing to help as I can if that saves from from having to takeover
an old kernel again on my week-ends.

One of my impression, which might or might not be shared, is that the
duration is more important than the frequency, which means that having
one extended kernel every two years would bring much more value than
maintaining all of them only 3 years, and would equally result in cutting
the effort in half: with 6 years, you still have 5 years if you upgrade
every two years.

> What would you do if you were in my situation?

I'd continue to ask for a shared effort for extended support, which
everyone benefits from.

Maybe one possibility would be to start gauging upfront around september
whether or not the end-of-year's LTS should be an extended LTS or not,
and if so, what's needed and who's willing to particpate. I suspect that
numerous companies have available resources to help but are not even
aware that they could help, and they're seeing something which works
extremely well so there's nothing to try to improve. And if nobody
provides resources, it means there's not enough interest to create yet
another extra LTS kernel so better save the effort.

Just my two cents,
Willy

  reply index

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 [this message]
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
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 \
    --in-reply-to=20210126201543.GA16044@1wt.eu \
    --to=w@1wt.eu \
    --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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git