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

[Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>]

On Wed, 5 Jul 2017 09:09:51 -0400
Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> This problem is a reflection of our own explicit or implicit priorities.
> The priorities of developers and reviewers needs to change to make an
> impact on the problem. This is a hard problem.

I 100% agree.

> 
> As a concrete action item, glibc core developers took a harder stance on
> (a) all user-visible bugs need a bug # (forces people to think about the

Unfortunately, we don't have a good system for a "bug #". Most kernel
developers hate bugzilla, and I think that includes Linus ;-) Which
means, unless Linus builds us a new bug tracking system, there wont be
any mandate for it.


> problem and file a coherent public bug about it) (b) all bugs needs a
> regression test if possible, (c) and if not possible we need to extend

I would love all bug fixes to come with a test (when possible).

> the testing framework to make it possible (we've started using kernel
> namespaces to create isolated test configurations).

Well, we have a selftest directory that should include all of these.
And most people run them on either a test box or a VM.

> 
> This change in reviewer priorities has had a noticeable impact on developer
> priorities over the last 5 years. Timelines for this problem will be
> measured in years.
> 

Your "b" above is what I would like to push. But who's going to enforce
this? With 10,000 changes per release, and a lot of them are fixes, the
best we can do is the honor system. Start shaming people that don't
have a regression test along with a Fixes tag (but we don't want people
to fix bugs without adding that tag either). There is a fine line one
must walk between getting people to change their approaches to bugs and
regression tests, and pissing them off where they start doing the
opposite of what would be best for the community.

-- Steve