On Mon, Feb 27, 2023 at 09:47:48AM -0800, Eric Biggers wrote: > > > > Of course, it's not just me that AUTOSEL isn't working for. So, you'll still > > > > continue backporting random commits that I have to spend hours bisecting, e.g. > > > > https://lore.kernel.org/stable/20220921155332.234913-7-sashal@xxxxxxxxxx. > > > > > > > > But at least I won't have to deal with this garbage for my own commits. > > > > > > > > Now, I'm not sure I'll get a response to this --- I received no response to my > > > > last AUTOSEL question at > > > > https://lore.kernel.org/stable/Y1DTFiP12ws04eOM@sol.localdomain. So to > > > > hopefully entice you to actually do something, I'm also letting you know that I > > > > won't be reviewing any AUTOSEL mails for my commits anymore. > > > > > > > > > > The really annoying thing is that someone even replied to your AUTOSEL email for > > > that broken patch and told you it is broken > > > (https://lore.kernel.org/stable/d91aaff1-470f-cfdf-41cf-031eea9d6aca@xxxxxxxxxxx), > > > and ***you ignored it and applied the patch anyway***. > > > > > > Why are you even sending these emails if you are ignoring feedback anyway? > > > > I obviously didn't ignore it on purpose, right? > > > > I don't know, is it obvious? You've said in the past that sometimes you'd like > to backport a commit even if the maintainer objects and/or it is known buggy. > https://lore.kernel.org/stable/d91aaff1-470f-cfdf-41cf-031eea9d6aca@xxxxxxxxxxx > also didn't explicitly say "Don't backport this" but instead "This patch has > issues", so maybe that made a difference? > > Anyway, the fact is that it happened. And if it happened in the one bug that I > happened to look at because it personally affected me and I spent hours > bisecting, it probably is happening in lots of other cases too. So it seems the > process is not working... > > Separately from responses to the AUTOSEL email, it also seems that you aren't > checking for any reported regressions or pending fixes for a commit before > backporting it. Simply searching lore for the commit title > https://lore.kernel.org/all/?q=%22drm%2Famdgpu%3A+use+dirty+framebuffer+helper%22 > would have turned up the bug report > https://lore.kernel.org/dri-devel/20220918120926.10322-1-user@am64/ that > bisected a regression to that commit, as well as a patch that Fixes that commit: > https://lore.kernel.org/all/20220920130832.2214101-1-alexander.deucher@xxxxxxx/ > Both of these existed before you even sent the AUTOSEL email! > > So to summarize, that buggy commit was backported even though: > > * There were no indications that it was a bug fix (and thus potentially > suitable for stable) in the first place. > * On the AUTOSEL thread, someone told you the commit is broken. > * There was already a thread that reported a regression caused by the commit. > Easily findable via lore search. > * There was also already a pending patch that Fixes the commit. Again easily > findable via lore search. > > So it seems a *lot* of things went wrong, no? Why? If so many things can go > wrong, it's not just a "mistake" but rather the process is the problem... BTW, another cause of this is that the commit (66f99628eb24) was AUTOSEL'd after only being in mainline for 4 days, and *released* in all LTS kernels after only being in mainline for 12 days. Surely that's a timeline befitting a critical security vulnerability, not some random neural-network-selected commit that wasn't even fixing anything? - Eric
