From: "Theodore Ts'o" <tytso@mit.edu>
To: Sasha Levin <sashal@kernel.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Eric Biggers <ebiggers@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: Sun, 12 Mar 2023 15:03:28 -0400 [thread overview]
Message-ID: <20230312190328.GL860405@mit.edu> (raw)
In-Reply-To: <ZAzDTVluocRvZ8W8@sashalap>
On Sat, Mar 11, 2023 at 01:07:09PM -0500, Sasha Levin wrote:
> > I think the one thing everyone on this thread might agree on is that
> > this bug wouldn't have happened if AUTOSEL could detect and backport
> > series instead of individual patches. Sasha says that can't be done
> > based on in information in Linus' tree[1] which is true but not a
> > correct statement of the problem. The correct question is given all
> > the information available, including lore, could we assist AUTOSEL in
> > better detecting series and possibly making better decisions generally?
>
> My argument was that this type of issue is no AUTOSEL specific, and we
> saw it happening multiple times with stable tagged patches as well.
I suspect that it happens *less* with Greg's patches, since the people
who add (and it's almost always remove) the Cc: tags have the
dependency information fresh in their brains' caches, and are more
likely to correctly tag which patches should and shouldn't have Cc:
stable tags.
Now, if after I've carefully annotated a patch series, some with Cc:
stable tags, and some without, and AUTOSEL were to override my work
and take some extra patches, that I had deliberately not tagged with
Cc: stable, I can (and have) gotten mildly annoyed, but in general, it
means that something which probably shouldn't and didn't need to go
into an LTS kernel ended up going into an LTS kernel, and TBH, when
this has happened, I don't worry about it *too* much. It probably has
made LTS less sstable when this happens, but it's generally not a
disaster.
In any case, I think the problem of missing dependencies when they are
in a patch series is *primarily* an AUTOSEL problem, and as I said,
probably can be fixed by using the information in lore.
I'll note that we can probably make the "was this part of the patch
series" work even better by encouraging contributors not to take
unrelated patches and put them unnecessarily into a patch series. So
if I knew that the stable bots were taking patch series into account,
or were about to start taking advantage of this signal, I'd be happy
to push back on contributors to break up patch series that should be
glommed together.
- Ted
next prev parent reply other threads:[~2023-03-12 19:03 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 [this message]
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
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=20230312190328.GL860405@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ebiggers@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).