Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <a1f1ad90-5f66-c73f-06ce-4ce65d079d1b@amd.com>
Date:   Mon, 16 Jan 2023 13:16:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Content-Language: en-US
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>
References: <CAPDLWs-Z8pYkwQ13dEgHXqSCjiq4xVnjuAXTy26H3=8NZCpV_g@mail.gmail.com>
 <Yz/ZWBeNZvKenEVM@kroah.com>
 <CAPDLWs9KWKs_-fpAp2=97uBARYqrHSYTPEU6RbqtWjAD8NpqgQ@mail.gmail.com>
 <CAPDLWs9CoWw7NLfrtCfMsRAdCSfBgomVELRhM70QWVca99z65A@mail.gmail.com>
 <Y53BputYK+3djDME@kroah.com> <c6c4787f-f0c6-7285-f782-d36bd86b1e01@amd.com>
 <96e41e6d-bec9-f8cf-22ed-1fa5d9022238@amd.com> <Y8FAFAwB9gBzQXQG@kroah.com>
 <314489f6-cb54-fb3b-6557-d69b1284fa4d@amd.com> <Y8GFYEnIy0Wbh/n6@kroah.com>
 <Y8HPw2t+TbdXa83C@mit.edu>
From:   Michal Simek <michal.simek@amd.com>
Subject: Re: Reg the next LTS kernel (6.1?)
In-Reply-To: <Y8HPw2t+TbdXa83C@mit.edu>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2023 12:16:38.2678
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d95d5e8a-795a-41bf-781e-08daf7bb84a9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource: BL02EPF00010206.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5766
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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