Determining patch impact on a specific config

[Greg KH]

Ok, just one response to this every growing thread, I think me and
Nicholas need to sit down over a beverage and work this out in person
instead of boring everyone on the list...

On Wed, Aug 17, 2016 at 06:48:53PM +0000, Nicholas Mc Guire wrote:
> I think we are looking at it from different angles here - our intent is to 
> uncover high-level faults in the develoment life-cycle - thinkgs that start
> going off track, like fix-rates going up or complexity metrics jumping, bug
> ages changing statitically significantly. e.g. ext4 has kind of poped out
> as a problem case - we can´t yet really say much why but from what Ive been
> looking at it seems that the problem goes all the way back to the initial
> release as a copy of ext3 rather than a clean re-implementation/re-design
> (This conclusion may well be wrong - its based on the observation that 
>  ext4 stable fixes are seemingly not stabilizing)

Ah, here's an example of what I was trying to say before.

ext4 is not any less or more "unstable" with more bugs than other
filesystems.  It's just that their developers and maintainer do send and
mark patches for the stable kernel trees.  The other filesystem
developers do not at all.

Yes, some bugfixes trickle in for other filesystems, but that's a very
rare occasion, and one major filesystem has the explicit rule that they
will NOT send any bugfixes for stable kernels because they just don't
want to worry about it and they want their users to always use the
latest kernel release to get the needed fixes.

So don't think that ext4 is more "unstable" than others, in fact, one
could argue that the ext4 developers are making their users _more_
stable than the other filesystems just because of these fixes :)

I think you might want to try to figure out how to look at the fixes
that go into Linus's kernel tree in order to try to get a better overall
picture.  Yes, it's a firehose, but that's what we have data analysis
tools for :)

good luck!

greg k-h