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:   Mon, 16 Jan 2023 22:07:25 -0500
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Michal Simek <michal.simek@amd.com>
Cc:     Kris Chaplin <kris.chaplin@amd.com>,
        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: <Y8YQ7SIRV3bG3iw1@mit.edu>
References: <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>
 <a1f1ad90-5f66-c73f-06ce-4ce65d079d1b@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a1f1ad90-5f66-c73f-06ce-4ce65d079d1b@amd.com>
Precedence: bulk

On Mon, Jan 16, 2023 at 01:16:33PM +0100, Michal Simek wrote:
> > 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.

The problem is that sometimes code meant for a particular SOC could
break other users.  The most extreme versions of this was an SOC
kernel that support in for big.little ARM CPU's that created generic
kernel .c files that *would* *not* *compile* on x86.  I've seen this
personally, and it impacted the ability for me to implement ext4
encryption for Chrome and Android, in that it worked fine on the
upstream kernel (because *I* develop my featuers upstream first), but
broke when I had to adapt and make chagnes for the SOC kernel that had
changs that had not been pushed upstream.

So if it hasn't been pushed to the upstream kernel, all of the testing
in the world in the SOC kernels doesn't count.  Push to upstream
*first*, and *then* backport to the SOC kernel.  Better yet, if all of
your device drivers are developed upstream first, then you might not
need that never to be sufficiently @#$?!@? SOC kernel...

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

If people don't listen to you, then they deserve all the pain that
they get, and upstream should not be bending over backwards for them.
And maybe we can try to get mobile device manufacturers to choose not
to chose that SOC when making choices for their next generation
flagship devices....

						- Ted