Re: AUTOSEL process

[Eric Biggers]

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