Re: [LSF/MM/BPF TOPIC] Filesystem backporting to stable

[Sasha Levin <sashal@kernel.org>]

On Tue, Feb 28, 2023 at 05:48:23PM -0800, Darrick J. Wong wrote:
>On Tue, Feb 28, 2023 at 03:46:11PM -0800, Leah Rumancik wrote:
>> The current standard for backporting to stable is rather ad hoc. Not
>> everyone will cc stable on bug fixes, and even if they do, if the
>> patch does not apply cleanly to the stable branches, it often gets
>> dropped if no one notices or cares enough to do the backporting.
>
>I'm very glad to see you stepping forward!
>
>> Historically, the XFS community has avoided backports via cc’ing
>> stable and via AUTOSEL due to concerns of accidentally introducing new
>> bugs to the stable branches. However, over the last year, XFS has
>> developed a new strategy for managing stable backports. A “stable
>> maintainer” role has been created for each stable branch to identify,
>> apply, and test potential backports before they are sent to the stable
>> mailing list. This provides better monitoring of the stable branches
>> which reduces the risk of introducing new bugs to stable and lessens
>> the possibility of bug fixes getting dropped on their way to stable.
>> XFS has benefited from this new backporting procedure and perhaps
>> other filesystems would as well.
>
>Given the recent roaring[1] between Sasha and Eric Biggers, I think this
>is a very apropos topic.  It's probably all right for robots to pick
>over driver patches and fling them into the LTS kernels, but filesystems
>are so complex that they really need experienced people to make
>judgement calls.

Which is fine in today's world, no? If a certain subsystem wants to do
it's own thing, it just makes our lives that much easier, and on that
note: thanks Leah & Amir!

>Another knot that I think we need to slice through is the question of
>what to do when support for LTS kernels becomes sparse.  Case in point:
>
>Oracle produces a kernel based on 5.4 and 5.15.  We're not going to
>introduce one based on 5.10.  If Amir stops supporting 5.10, what do we
>do about 5.4?  If a bugfix appears that needs to be applied to 5.4-6.1,
>Greg will not let Chandan backport it to 5.4 until Chandan either takes
>responsibility for 5.10, or tricks someone else into do it.  That's not
>fair to him, and Oracle isn't going to start supporting 5.10.  Preening
>online fsck parts 1 and 2 now consumes so much time that I don't have
>the bandwidth to embark on any of the iomap cleanups that are slowly
>getting more urgent.
>
>[I am very very grateful that you all came along!]
>
>So what do we do?  Do I beg the three of you to try to do 5.10 in your
>spare time, which isn't really fair to you or Amir.
>
>Proposal:
>
>How about we EOL the XFS code in the releases that nobody wants so that
>patches can keep flowing to the ones that are still wanted?

We're in the process of going away from 6 year kernels which will in
turn lessen the number of parallel trees we support.

OTOH, this raises the question of what Oracle plans to do after 5.4 goes
EOL?

-- 
Thanks,
Sasha