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;
Date:   Fri, 13 Jan 2023 16:40:19 -0500
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Michal Simek <michal.simek@amd.com>,
        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?)
Message-ID: <Y8HPw2t+TbdXa83C@mit.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y8GFYEnIy0Wbh/n6@kroah.com>
Precedence: bulk

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.

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.  :-)

						- 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.