From: Willy Tarreau <w@1wt.eu>
To: Matthew Wilcox <willy@infradead.org>
Cc: Eric Biggers <ebiggers@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Sasha Levin <sashal@kernel.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org
Subject: Re: AUTOSEL process
Date: Sat, 11 Mar 2023 09:11:34 +0100 [thread overview]
Message-ID: <ZAw3tt9xISOdb5sS@1wt.eu> (raw)
In-Reply-To: <ZAwe95meyCiv6qc4@casper.infradead.org>
On Sat, Mar 11, 2023 at 06:25:59AM +0000, Matthew Wilcox wrote:
> On Tue, Mar 07, 2023 at 09:45:24PM +0000, Eric Biggers wrote:
> > On Tue, Mar 07, 2023 at 10:18:35PM +0100, Pavel Machek wrote:
> > > 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
last years. A lot of processes have improved everywhere even before
the release, but I do think that autosel is part of what generally
gives a chance to some useful and desired fixed (e.g. in drivers) to
be backported and save some users unneeded headaches.
In fact I think that the reason for the negative perception is that
patches that it picks are visible, and it's easy to think "WTF" when
seeing one of them. Previously, these patches were not proposed, so
nobody knew they were missing. It happened to plenty of us to spend
some time trying to spot why a stable kernel would occasionally fail
on a machine, and discovering in the process that mainline did work
because it contained a fix that was never backported. This is
frustrating but there's noone to blame for failing to pick that patch
(and the patch's author should not be blamed either since for small
compatibility stuff it's probably common to see first-timers who are
not yet at ease with the process).
Here the patches are CCed to their authors before being merged. They
get a chance to be reviewed and rejected. Granted, maybe sometimes they
could be subject to a longer delay or be sent to certain lists. Maybe.
But I do think that the complaints in fact reflect a process that's not
as broken as some think, precisely because it allows people to complain
when something is going wrong. The previous process didn't permit that.
For this alone it's a progress.
Willy
next prev parent reply other threads:[~2023-03-11 8:12 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230226034256.771769-1-sashal@kernel.org>
2023-02-26 3:42 ` [PATCH AUTOSEL 6.1 07/21] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected Sasha Levin
2023-02-26 3:42 ` [PATCH AUTOSEL 6.1 12/21] fs/super.c: stop calling fscrypt_destroy_keyring() from __put_super() Sasha Levin
2023-02-26 4:07 ` Eric Biggers
2023-02-26 5:30 ` Eric Biggers
2023-02-26 19:24 ` Eric Biggers
2023-02-26 19:33 ` Slade Watkins
2023-02-27 14:18 ` Sasha Levin
2023-02-27 17:47 ` AUTOSEL process Eric Biggers
2023-02-27 18:06 ` Eric Biggers
2023-02-27 20:39 ` Sasha Levin
2023-02-27 21:38 ` Eric Biggers
2023-02-27 22:35 ` Sasha Levin
2023-02-27 22:59 ` Matthew Wilcox
2023-02-28 0:52 ` Sasha Levin
2023-02-28 1:25 ` Eric Biggers
2023-02-28 4:25 ` Willy Tarreau
2023-03-30 0:08 ` Eric Biggers
2023-03-30 14:05 ` Sasha Levin
2023-03-30 17:22 ` Eric Biggers
2023-03-30 17:50 ` Sasha Levin
2023-02-28 0:32 ` Eric Biggers
2023-02-28 1:53 ` Sasha Levin
2023-02-28 3:41 ` Eric Biggers
2023-02-28 10:41 ` Amir Goldstein
2023-02-28 11:28 ` Greg KH
2023-03-01 2:05 ` Slade Watkins
2023-03-01 5:13 ` Eric Biggers
2023-03-01 6:09 ` Greg KH
2023-03-01 7:22 ` Eric Biggers
2023-03-01 7:40 ` Willy Tarreau
2023-03-01 8:31 ` Eric Biggers
2023-03-01 8:43 ` Greg KH
2023-03-01 6:06 ` Greg KH
2023-03-01 7:05 ` Eric Biggers
2023-03-01 10:31 ` Thorsten Leemhuis
2023-03-01 13:26 ` Mark Brown
2023-02-28 17:03 ` Sasha Levin
2023-03-10 23:07 ` Eric Biggers
2023-03-11 13:41 ` Sasha Levin
2023-03-11 15:54 ` James Bottomley
2023-03-11 18:07 ` Sasha Levin
2023-03-12 19:03 ` Theodore Ts'o
2023-03-07 21:18 ` Pavel Machek
2023-03-07 21:45 ` Eric Biggers
2023-03-11 6:25 ` Matthew Wilcox
2023-03-11 8:11 ` Willy Tarreau [this message]
2023-03-11 11:45 ` Pavel Machek
2023-03-11 12:29 ` Greg KH
2023-03-21 12:41 ` Maciej W. Rozycki
2023-03-11 14:06 ` Sasha Levin
2023-03-11 16:16 ` Theodore Ts'o
2023-03-11 17:48 ` Eric Biggers
2023-03-11 18:26 ` Sasha Levin
2023-03-11 18:54 ` Eric Biggers
2023-03-11 19:01 ` Eric Biggers
2023-03-11 21:14 ` Sasha Levin
2023-03-12 8:04 ` Amir Goldstein
2023-03-12 16:00 ` Sasha Levin
2023-03-13 17:41 ` Greg KH
2023-03-13 18:54 ` Eric Biggers
2023-03-14 18:26 ` Greg KH
2023-03-11 20:17 ` Eric Biggers
2023-03-11 21:02 ` Sasha Levin
2023-03-12 4:23 ` Willy Tarreau
2023-03-11 18:33 ` Willy Tarreau
2023-03-11 19:24 ` Eric Biggers
2023-03-11 19:46 ` Eric Biggers
2023-03-11 20:19 ` Willy Tarreau
2023-03-11 20:59 ` Sasha Levin
2023-03-11 20:11 ` Willy Tarreau
2023-03-11 20:53 ` Eric Biggers
2023-03-12 4:32 ` Willy Tarreau
2023-03-12 5:21 ` Eric Biggers
2023-03-12 5:48 ` Willy Tarreau
2023-03-12 7:42 ` Amir Goldstein
2023-03-12 13:34 ` Mark Brown
2023-03-12 15:57 ` Sasha Levin
2023-03-12 13:55 ` Mark Brown
2023-03-11 22:38 ` David Laight
2023-03-12 4:41 ` Willy Tarreau
2023-03-12 5:09 ` Theodore Ts'o
2023-03-14 14:12 ` Jan Kara
2023-03-13 3:37 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZAw3tt9xISOdb5sS@1wt.eu \
--to=w@1wt.eu \
--cc=ebiggers@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).