On Mon, Feb 27, 2023 at 03:39:14PM -0500, Sasha Levin wrote:
> > 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?
I would love to have a mechanism that tells me with 100% confidence if a
given commit fixes a bug or not, could you provide me with one?
Just because you can't be 100% certain whether a commit is a fix doesn't mean
you should be rushing to backport random commits that have no indications they
are fixing anything.
w.r.t timelines, this is something that was discussed on the mailing
list a few years ago where we decided that giving AUTOSEL commits 7 days
of soaking time is sufficient, if anything changed we can have this
discussion again.
Nothing has changed, but that doesn't mean that your process is actually
working. 7 days might be appropriate for something that looks like a security
fix, but not for a random commit with no indications it is fixing anything.
BTW, based on that example it's not even 7 days between AUTOSEL and patch
applied, but actually 7 days from AUTOSEL to *release*. So e.g. if someone
takes just a 1 week vacation, in that time a commit they would have NAK'ed can
be AUTOSEL'ed and pushed out across all LTS kernels...
Note, however, that it's not enough to keep pointing at a tiny set and
using it to suggest that the entire process is broken. How many AUTOSEL
commits introduced a regression? How many -stable tagged ones did? How
many bugs did AUTOSEL commits fix?
So basically you don't accept feedback from individual people, as individual
people don't have enough data?