[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxietbePiWgw8aOZiZ+YT=5vYVdPH=ChnBkU_KCaHGv+1w@mail.gmail.com>
Date: Tue, 28 Feb 2023 12:41:07 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, viro@...iv.linux.org.uk,
linux-fsdevel@...r.kernel.org
Subject: Re: AUTOSEL process
> > I'm not sure how feedback in the form of "this sucks but I'm sure it
> > could be much better" is useful.
>
> I've already given you some specific suggestions.
>
> I can't force you to listen to them, of course.
>
Eric,
As you probably know, this is not the first time that the subject of the
AUTOSEL process has been discussed.
Here is one example from fsdevel with a few other suggestions [1].
But just so you know, as a maintainer, you have the option to request that
patches to your subsystem will not be selected by AUTOSEL and run your
own process to select, test and submit fixes to stable trees.
xfs maintainers have done that many years ago.
This choice has consequences though - for years, no xfs fixes were flowing
into stable trees at all, because no one was doing the backport work.
It is hard to imagine that LTS kernel users were more happy about this
situation than they would be from occasional regressions, but who knows...
It has taken a long time until we found the resources and finally started a
process of reviewing, testing and submitting xfs fixes to stable trees and this
process involves a lot of resources (3 maintainers + $$$), so opting out of
AUTOSEL is not a clear win.
I will pencil down yet another discussion on fs and stable process at
LSFMM23 to update on the current status with xfs, but it is hard to
believe that this time we will be able to make significant changes to
the AUTOSEL process.
Thanks,
Amir.
[1] https://lore.kernel.org/linux-fsdevel/20201204160227.GA577125@mit.edu/#t
Powered by blists - more mailing lists