[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAxp0KaKq7x7ZKlz@duo.ucw.cz>
Date: Sat, 11 Mar 2023 12:45:20 +0100
From: Pavel Machek <pavel@....cz>
To: Willy Tarreau <w@....eu>
Cc: Matthew Wilcox <willy@...radead.org>,
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
Hi!
> > > > I believe that -stable would be more useful without AUTOSEL process.
> > >
> > > There has to be a way to ensure that security fixes that weren't properly tagged
> > > make it to stable anyway. So, AUTOSEL is necessary, at least in some form. I
> > > think that debating *whether it should exist* is a distraction from what's
> > > actually important, which is that the current AUTOSEL process has some specific
> > > problems, and these specific problems need to be fixed...
> >
> > I agree with you, that we need autosel and we also need autosel to
> > be better. I actually see Pavel's mail as a datapoint (or "anecdote",
> > if you will) in support of that; the autosel process currently works
> > so badly that a long-time contributor thinks it's worse than nothing.
> >
> > Sasha, what do you need to help you make this better?
>
> One would probably need to define "better" and "so badly". As a user
> of -stable kernels, I consider that they've got much better over the
Well, we have Documentation/process/stable-kernel-rules.rst . If we
wanted to define "better", we should start documenting what the real
rules are for the patches in the stable tree.
I agree that -stable works quite well, but the real rules are far away
from what is documented.
I don't think AUTOSEL works well. I believe we should require positive
reply from patch author on relevant maintainer before merging such
patch to -stable.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists