Thread (1 message) 1 message, 1 author, 2017-07-05

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] & [TECH TOPIC] Improve regression tracking

From: Steven Rostedt <hidden>
Date: 2017-07-05 16:04:59

On Wed, 05 Jul 2017 08:36:55 -0700
James Bottomley [off-list ref] wrote:
quoted
Are we tracking regressions or just simply bugs?  
A lot of device driver regressions are bugs that previously existed in
the code but which didn't manifest until something else happened.  A
huge number of locking and timing issues are like this.  The irony is
that a lot of them go from race always being won (so bug never noticed)
to race being lost often enough to make something unusable.  To a user
that ends up being a kernel regression because it's a bug in the
current kernel which they didn't see previously which makes it unusable
for them.

I've got to vote with my users here: that's a regression not a
"feature".
Let's take a step back. What exactly is the problem?

The regressions that we want to track? Why are they not fixed? Is it
because they are hard to reproduce? If so, how do we know they are a
regression or just some hard to hit bug? If it's hard to hit, how do we
know we fixed it?

What exactly are the questions we want solved.

Granted, I used this thread to push more use of kselftests, and I don't
see any SCSI tests there at all!

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