On Wed, 5 Jul 2017 09:09:51 -0400 Carlos O'Donell <carlos@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
