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, 7 Oct 2022 15:50:12 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Carl Dasantas <dasantas2020@gmail.com>
Cc:     Greg KH <gregkh@linuxfoundation.org>, kaiwan.billimoria@gmail.com,
        linux-kernel@vger.kernel.org
Subject: Re: Reg the next LTS kernel (6.1?)
Message-ID: <Y0CC9IfhWj+/DXTp@mit.edu>
References: <CANNVxH_uwnz31kak4fKAVuj8UP4wbWcFiDQ+kFwTametBvixGA@mail.gmail.com>
 <Y0BHYPat6L+FZFGQ@kroah.com>
 <CANNVxH_fDjD2TU0ccW19hSKXwTL+m6kDPr6n7=36uipStgwzGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANNVxH_fDjD2TU0ccW19hSKXwTL+m6kDPr6n7=36uipStgwzGA@mail.gmail.com>
Precedence: bulk

On Fri, Oct 07, 2022 at 12:07:05PM -0400, Carl Dasantas wrote:
> It's moreso the fact that initial Rust support is being added. Yes I
> know it's just initial support/NVMe drivers.

Care to name a *single* functional kernel feature (whether a device
driver or not) that is dependent on RUST.  Have you tried building the
latest development kernel without rust --- what happens?  (hint: nothing)

> Also, Rust support isn't the only major
> change in 6.1, by the kernel.orgs own site (time permitting) an LTS is
> made if major changes are present.

This is simply not true.  The start of a new LTS kernel has always
been time-based, and there certainly have been attempts to get new
major functionality around this time of year in the hopes that it can
be made avcailable in distro kernels.  Of course, if the functionality
or change is too flaky, it could very well get reverted or the
distributions will simply not enable the feature because it would be a
support nightmare for them.

All of this does not apply for Rust.  Again, take a look at what is
*actually* been included during the current merge window.

Regards,

						- Ted