a word on regressions

[Dave Airlie]

I've been looking a bit at 5.0 for a few things recently, and I've
noticed it shipped with a bunch of regressions, that I'm trying to
smash.

udl driver regression due to gem unlocked cleanup
udl driver unload regression due to other unplug changes
i915 + atomic x.org modesetting driver break
i915 eDP faster/stronger/wider patch fallout
virtio-gpu prime removal broke DRI3

Now in some of the cases here a revert has had to be argued for by me,
and in some cases a revert hasn't happened as quickly as I'd like.

But one thing I've seen in a couple of cases is regression nitpicking,
which isn't acceptable to Linus and hence to me either.

if the sequence happens:
kernel A does something
apply patch X
kernel A+X doesn't do the same thing

then patch X is broken and needs to be reverted
- no matter what patch X fixes
- no matter if the fault patch X uncovers is somewhere in userspace or
in magic other lands,
- no matter if patch X revert regresses something patch X fixes.

I do not want to hear excuses that this patch isn't at fault, or it's
the other userspace problem, it's your problem to engineer around
that, wait 5 years, new CONFIG options, detecting the buggy userspace,
whatever, you are engineering something, go engineer it.

For anyone interested I've reverted the i915 atomic fbdev fix, the
virtio-gpu prime removal, i915 team already did the eDP reverts, and I
did two fixes for udl.

Dave.