linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>, Sasha Levin <sashal@kernel.org>,
	Matthew Wilcox <willy@infradead.org>, Pavel Machek <pavel@ucw.cz>,
	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 19:33:58 +0100	[thread overview]
Message-ID: <ZAzJltJaydwjCN6E@1wt.eu> (raw)
In-Reply-To: <ZAy+3f1/xfl6dWpI@sol.localdomain>

On Sat, Mar 11, 2023 at 09:48:13AM -0800, Eric Biggers wrote:
> The purpose of all these mailing list searches would be to generate a list of
> potential issues with backporting each commit, which would then undergo brief
> human review.

This is one big part that I suspect is underestimated. I'll speak from my
past experience maintaining extended LTS for 3.10. I couldn't produce as
many releases as I would have liked to because despite the scripts that
helped me figure some series, some dependencies, origin branches etc, the
whole process of reviewing ~600 patches to end up with ~200 at the end
(and adapting some of them to fit) required ~16 hours a day for a full
week-end, and I didn't always have that amount of time available. Any my
choices were far from being perfect, as during the reviews I got a number
of "please don't backport this there" and "if you take this one you also
need these ones". Also I used to intentionally drop what had nothing to
do on old LTS stuff so even from that perspective my work could have been
perceived as insufficient.

The reviewing process is overwhelming, really. There is a point where you
start to fail and make choices that are not better than a machine's. But
is a mistake once in a while dramatic if on the other hand it fixes 200
other issues ? I think not as long as it's transparent and accepted by
the users, because for one user that could experience a regression (one
that escaped all the testing in place), thousands get fixes for existing
problems. I'm not saying that regressions are good, I hate them, but as
James said, we have to accept that user are part of the quality process.

My approach on another project I maintain is to announce upfront my own
level of trust in my backport work, saying "I had a difficult week fixing
that problem, do not rush on it or be extra careful", or "nothing urgent,
no need to upgrade if you have no problem" or also "just upgrade, it's
almost riskless". Users love that, because they know they're part of the
quality assurance process, and they will either take small risks when
they can, or wait for others to take risks.

But thinking that having one person review patches affecting many
subsystem after pre-selection and extra info regarding discussions on
each individual patch could result in more reliable stable releases is
just an illusion IMHO, because the root of problem is that there are not
enough humans to fix all the problems that humans introduce in the first
place, and despite this we need to fix them. Just like automated scripts
scraping lore, AUTOSEL does bring some value if it offloads some work
from the available humans, even in its current state. And I hope that
more of the selection and review work in the future will be automated
and even less dependent on humans, because it does have a chance to be
more reliable in front of that vast amount of work.

And in any case I've seen you use the word "trivial" several times in
this thread, and for having been through a little bit of this process
in the past, I wouldn't use that word anywhere in a description of what
my experience had been. You really seem to underestimate the difficulty
here.

Regards,
Willy

  parent reply	other threads:[~2023-03-11 18:34 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
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 [this message]
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=ZAzJltJaydwjCN6E@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=tytso@mit.edu \
    --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).