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.