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: > > > 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. > > > > 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 ? Well, there is not much people can do with 1000 patches with no context, but if there's a much shorter list of potential issues to pay attention to, I'd hope that would be helpful. > > I checked the entire email thread > > (https://lore.kernel.org/stable/?q=f%3Aebiggers+trivial). The only place I used > > the word "trivial" was mentioning that querying lore.kernel.org from a Python > > script might be trivial, which is true. > > I'm unable to do it, so at best it's trivial for someone at ease with > Python and the lore API. And parsing the results and classifying them > might not be trivial at all either. Getting information is one part, > processing it is another thing. > > > And also in my response to Sasha's > > similar false claim that I was saying everything would be trivial. > > > > I'm not sure why you're literally just making things up; it's not a very good > > way to have a productive discussion... > > I'm not making things up. Maybe you wrote "trivial" only once but the tone > of your suggestions from the beginning was an exact description of something > called trivial and made me feel you find all of this "trivial", which you > finally confirmed in that excerpt above. You are indeed making things up, which is annoying as it makes it hard to have a real discussion. Anyway, hopefully we can get past that. > Quite frankly, I'm not part of this process anymore and am really thankful > that the current maintainers are doing that work. But it makes me feel > really uneasy to read suggestions basically sounding like "why don't you > fix your broken selection process" or "it should just be as trivial as > collecting the missing info from lore". Had I received such contemptuous > "suggestions" when I was doing that job, I would just have resigned. And > just saying things like "I will not start helping before you change your > attitude" you appear infantilizing at best and in no way looking like > you're really willing to help. Sasha said he was open to receive proposals > and suddenly the trivial job gets conditions. Just do your part of the > work that seems poorly done to you, and everyone will see if your ideas > and work finally helped or not. Nobody will even care if it was trivial > or if it ended up taking 4 months of refining, as long as it helps in > the end. But I suspect that you're not interested in helping, just in > complaining. > > 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'll try to put something together, despite all the pushback I'm getting. But by necessity it will be totally separate from the current stable scripts, as it seems there is no practical way for me to do it otherwise, given that the current stable process is not properly open and lacks proper leadership. - Eric
