Message-ID: <ZA3Z7Gdigi2cBWQu@sirena.org.uk>
Date:   Sun, 12 Mar 2023 13:55:56 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     Eric Biggers <ebiggers@...nel.org>, Theodore Ts'o <tytso@....edu>,
        Sasha Levin <sashal@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-fsdevel@...r.kernel.org
Subject: Re: AUTOSEL process

On Sat, Mar 11, 2023 at 09:11:51PM +0100, Willy Tarreau wrote:
> On Sat, Mar 11, 2023 at 11:24:31AM -0800, Eric Biggers wrote:

> > As I said in a part of my email which you did not quote, the fallback option is
> > to send the list of issues to the mailing list for others to review.

> Honestly, patches are already being delivered publicly tagged AUTOSEL,
> then published again as part of the stable review process. Have you seen
> the amount of feedback ? Once in a while there are responses, but aside
> Guenter reporting build successes or failures, it's a bit quiet. What
> makes you think that sending more detailed stuff that require even more
> involvement and decision would trigger more participation ?

TBH as someone getting copied on the AUTOSEL mails I think if the
volume of backports is going to say the same what I'd really like
is something that mitigates the volume of mail, or at least makes
the mails that are being sent more readily parseable.  Things
that add more context to what's being sent would probably help a
lot, right now I'm not really able to do much more than scan for
obviously harmful things.

> > But again, this comes back to one of the core issues here which is how does one
> > even build something for the stable maintainers if their requirements are
> > unknown to others?

> Well, the description of the commit message is there for anyone to
> consume in the first place. A commit message is an argument for a
> patch to get adopted and resist any temptations to revert it. So
> it must be descriptive enough and give instructions. Dependencies
> should be clear there. When you seen github-like one-liners there's
> no hope to get much info, and it's not a matter of requirements,
> but of respect for a team development process where some facing your
> patch might miss the skills required to grasp the details. With a
> sufficiently clear commit message, even a bot can find (or suggest)
> dependencies. And this is not specific to -stable: if one of the
> dependencies is found to break stuff, how do you know it must not be
> reverted without reverting the whole series if that's not described
> anywhere ?

I'd say that the most common class of missing dependency I've
seen is on previously applied code which is much less likely to
be apparent in the commit message and probably not noticed unless
it causes a cherry pick or build issue.

> One thing I think that could be within reach and could very slightly
> improve the process would be to indicate in a stable announce the amount
> of patches coming from autosel. I think that it could help either
> refining the selection by making users more conscious about the importance
> of this source, or encourage more developers to Cc stable to reduce that
> ratio. Just an idea.

I'm not sure if it's the ratio that's the issue here, if anything
I'd expect that lowering the ratio would make people more
stressed by AUTOSEL since assuming a similar volume of patches
get picked overall it would increase the percentage of the
AUTOSEL patches that have problems.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists