linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@amd.com>
To: Theodore Ts'o <tytso@mit.edu>, Kris Chaplin <kris.chaplin@amd.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Reg the next LTS kernel (6.1?)
Date: Mon, 16 Jan 2023 13:16:33 +0100	[thread overview]
Message-ID: <a1f1ad90-5f66-c73f-06ce-4ce65d079d1b@amd.com> (raw)
In-Reply-To: <Y8HPw2t+TbdXa83C@mit.edu>



On 1/13/23 22:40, Theodore Ts'o wrote:
> On Fri, Jan 13, 2023 at 05:22:56PM +0100, Greg KH wrote:
>>> I am just saying that developers/driver owners can simple do calculation to
>>> identify LTS version. When they know it they also know time when their
>>> deadline is for upstreaming work. It means if patch is accepted between
>>> 6.0-r1 and 6.0-rc5/6 they know that it will get to 6.1 merge window.
>>
>> That is what I am afraid of and if it causes problems I will purposfully
>> pick the previous release.  This has happened in the past and is never
>> an excuse to get anything merged.  Code gets merged when it is ready,
>> not based on a LTS release.
> 
> This is probably the best reason not to preannounce when the LTS
> release will be ahead of time --- because it can be abused by
> developers who try to get not-ready-for-prime-time features into what
> they think will be the LTS kernel, with the result that the last
> release of the year could be utterly unsitable for that perpose.

None is saying that not-ready-for-prime-time feature is pushed.
In our case all code before upstream goes to soc vendor and it stays there for 
quite a long time when developers have time to upstream it.
I can imagine that this can happen when you use upstream first solution where 
the code is not fully tested on all configurations.

> 
> What I would try to tell people who are trying to get a feature into
> the enterprise distro kernel is to target a release in the *middle*a
> of the year, so that there is plenty of time to stablize it before the
> LTS kernel is cut.
 >> Alternatively, I might work with the team reasponsible for release
> engineering the "product" kernel that I might be targetting (for
> example, for my company's Cloud Optimized OS) and since they follow
> the "upstream first" principle, once the feature is upstream, they
> will backport it into the various LTS release which we support for our
> cloud customers.  And if it just so happens that Amazon Linux doesn't
> have the feature, but my company's cloud OS does ---- well, that's the
> way the cookie crumbles, and that's why the wise distro company will
> have kernel developers on staff, not just try to freeload off of the
> LTS maintainers.  :-)

We are a little bit different case. We are pretty much not making products. We 
are doing SOC enablement to show the latest features on the latest silicon.
But our customers/users are making products based on code we developed for them.
That's why I am telling to developers to upstream code whenever it is ready to 
be upstreamed but not everybody is following recommendations . And for new SOCs 
we should be couple of months ahead for any customer that's why it shouldn't 
really matter if that feature goes to one or another kernel.

> 
> 						- Ted
> 
> P.S.  And if you work for a hardware company, in general the LTS
> maintainers have been willing to handle backporting device drivers to
> older LTS kernels, since your customers might very well might want to
> stay on 5.15, 5.10, 5.4, etc.  Of course, if your feature requires
> massive surgery all over the kernel, that's even more of a reason not
> incentivize people to make massive, risky changes right before the LTS
> kernel is cut.

This is the first time when I hear about it. I think that LTSI kernel guys for 
supporting kernel for extended period they are doing it but never heard that it 
can be also done for regular LTS kernels.
Anyway we don't need it but it is good to be aware about it.

Thanks,
Michal

  parent reply	other threads:[~2023-01-16 12:16 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07  7:37 Reg the next LTS kernel (6.1?) Kaiwan N Billimoria
2022-10-07  7:46 ` Greg KH
2022-10-07  7:50   ` Kaiwan N Billimoria
2022-12-17 13:02     ` Kaiwan N Billimoria
2022-12-17 13:18       ` Greg KH
2022-12-17 13:44         ` Kaiwan N Billimoria
2022-12-17 16:40           ` Willy Tarreau
2022-12-20  1:45             ` Kaiwan N Billimoria
2022-12-18  8:42           ` Greg KH
2023-01-11  8:15         ` Conor Dooley
2023-01-11 11:33           ` Greg KH
2023-01-11 19:05             ` Conor Dooley
2023-01-12 12:23         ` Kris Chaplin
2023-01-12 12:26           ` Michal Simek
2023-01-13 11:27             ` Greg KH
2023-01-13 12:54               ` Michal Simek
2023-01-13 16:22                 ` Greg KH
2023-01-13 21:40                   ` Theodore Ts'o
2023-01-14  7:14                     ` Willy Tarreau
2023-01-14  8:26                       ` Greg KH
2023-01-14  8:47                         ` Willy Tarreau
2023-02-05  6:27                         ` Ruslan Bilovol
2023-02-16 10:41                           ` Kris Chaplin
2023-02-16 11:20                             ` Greg KH
2023-02-16 11:23                               ` Kris Chaplin
2023-01-16 12:16                     ` Michal Simek [this message]
2023-01-17  3:07                       ` Theodore Ts'o
2023-01-16 12:02                   ` Michal Simek
2023-01-13 11:24           ` Greg KH
2022-10-07 15:04 Carl Dasantas
2022-10-07 15:36 ` Greg KH
2022-10-07 16:07   ` Carl Dasantas
2022-10-07 16:34     ` Greg KH
2022-10-07 19:50     ` Theodore Ts'o
2022-10-07 17:37 ` Slade Watkins

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=a1f1ad90-5f66-c73f-06ce-4ce65d079d1b@amd.com \
    --to=michal.simek@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kris.chaplin@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 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).