MIME-Version: 1.0
References: <ZAewdAql4PBUYOG5@gmail.com> <ZAwe95meyCiv6qc4@casper.infradead.org>
 <ZAyK0KM6JmVOvQWy@sashalap> <20230311161644.GH860405@mit.edu>
 <ZAy+3f1/xfl6dWpI@sol.localdomain> <ZAzJltJaydwjCN6E@1wt.eu>
 <ZAzVbzthi8IfptFZ@sol.localdomain> <ZAzghyeiac3Zh8Hh@1wt.eu>
 <ZAzqSeus4iqCOf1O@sol.localdomain> <ZA1V4MbG6U3wP6q6@1wt.eu> <ZA1hdkrOKLG697RG@sol.localdomain>
In-Reply-To: <ZA1hdkrOKLG697RG@sol.localdomain>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Sun, 12 Mar 2023 09:42:59 +0200
Message-ID: <CAOQ4uxiJPvKh5VzoP=9xamFfU78r3J25pwW6GQyAUN7YPJk=dQ@mail.gmail.com>
Subject: Re: AUTOSEL process
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Willy Tarreau <w@1wt.eu>, "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,
        Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Mar 12, 2023 at 7:41=E2=80=AFAM Eric Biggers <ebiggers@kernel.org> =
wrote:
>
...
> I mean, "patches welcome" is a bit pointless when there is nothing to pat=
ch, is
> it not?  Even Sasha's stable-tools, which he finally gave a link to, does=
 not
> include anything related to AUTOSEL.  It seems AUTOSEL is still closed so=
urce.
>
> BTW, I already did something similar "off to the side" a few years ago wh=
en I
> wrote a script to keep track of and prioritize syzbot reports from
> https://syzkaller.appspot.com/, and generate per-subsystem reminder email=
s.
>
> I eventually ended up abandoning that, because doing something off to the=
 side
> is not very effective and is hard to keep up with.  The right approach is=
 to
> make improvements to the "upstream" process (which was syzbot in that cas=
e), not
> to bolt something on to the side to try to fix it after the fact.
>
> So I hope people can understand where I'm coming from, with hoping that w=
hat the
> stable maintainers are doing can just be improved directly, without first
> building something from scratch off to the side as that is just not a goo=
d way
> to do things.  But sure, if that's the only option to get anything nontri=
vial
> changed, I'll try to do it.
>

Eric,

Did you consider working to improve or add functionality to b4?

Some of the things that you proposed sound like a natural extension of
b4 that stable maintainers could use if they turn out to be useful.

Some of the things in your wish list, b4 already does - it has a local
cache of messages from query results, it can find the latest submission
of a patch series.

When working on backporting xfs patches to LTS, I ended up trying to
improve and extend b4 [1].

My motivation was to retrieve the information provided in the pull request
and cover letters which often have much better context to understand
whether patches are stable material.

My motivation was NOT to improve automatic scripts, but I did make
some improvement to b4 that could benefit automatic scripts as well.

Alas, despite sending a pull request via github and advertising my work
and its benefits on several occasions, I got no feedback from Konstantin
nor from any other developers, so I did not pursue upstreaming.

If you find any part of this work relevant, I can try to rebase and
post my b4 patches.

Thanks,
Amir.

[1] https://github.com/mricon/b4/pull/1