Thread (12 messages) 12 messages, 6 authors, 2026-04-10

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

flat view

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2026-03-20 21:03:49
Also in: linux-bluetooth

On Fri, 20 Mar 2026 at 11:02, Luiz Augusto von Dentz
[off-list ref] wrote:
Bluetooth regressions are normally device-specific, though. In this
case, the regression was introduced to pass a new Bluetooth
Qualification test, so we would have to weigh what is more important:
compliance or interoperability?
What?

That's nonsensical.

Compliance with some paper standard or artificial test is *COMPLETELY*
irrelevant in the face of an actual user experience regression.

Because when reality and theory collide, theory goes out the window.

There's no "weighing what is more important". None. Users are a
million times more important than specs or tests.

And yes, the world is full of hardware that is not actually compliant
with various standards that it's _supposed_ to be compliant with.

That hardware may admittedly often not be great, and we may all wish
that it didn't exist, but hey, that's the thing about reality: it's
often messy.

And sometimes it's the standard that is wrong.
I can't remove a valid compliance fix just because
a user (later more appeared which raized the severity) said his device
stopped working.
Of course you can.

The test or the standard may be entirely invalid. Not unheard of.

But even more common is that the "fix" that made the test work may
simply be wrong.

Because that "fix some case, break something else" is in a fairly
common pattern.  And that just makes the fix invalid and buggy.

And we have a hard rule on regressions exactly BECAUSE of that
situation: having a "fix one thing, break another" is what the
suspend/resume code had for years and years.

The constant "one step forward, two steps back" dance was what made us
have that hard rule about regressions, because it's better to have a
stable base with known problems - that you can perhaps document - than
have a base where the problems just shift around like quicksand and
users are understandably nervous about upgrading their system, because
they never know if the end result works or not.

So the whole "it's a fix so we can't remove it" is simple not a valid
argument. It's absolutely wrong. Because a fix that causes regressions
is BY DEFINITION not a fix at all.

                Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help