[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/3lV0P9h+FxmjyF@kroah.com>
Date: Tue, 28 Feb 2023 12:28:23 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: Eric Biggers <ebiggers@...nel.org>,
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
On Tue, Feb 28, 2023 at 12:41:07PM +0200, Amir Goldstein wrote:
> > > 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.
Yes, and simply put, that's the answer for any subsystem or maintainer
that does not want their patches picked using the AUTOSEL tool.
The problem that the AUTOSEL tool is solving is real, we have whole
major subsystems where no patches are ever marked as "for stable" and so
real bugfixes are never backported properly.
In an ideal world, all maintainers would properly mark their patches for
stable backporting (as documented for the past 15+ years, with a cc:
stable tag, NOT a Fixes: tag), but we do not live in that world, and
hence, the need for the AUTOSEL work.
thanks,
greg k-h
Powered by blists - more mailing lists