On Wed, Jul 05, 2017 at 09:09:51AM -0400, Carlos O'Donell 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.

Take a look at the trajectory for the build and boot testing for a
concrete example of this - the failure rates go down over time but it's
not a quick process.

> 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
> 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
> the testing framework to make it possible (we've started using kernel
> namespaces to create isolated test configurations).

One thing I'd really like to see here is an equivalent of the build and
boot testing we currently have that exercises some of the testsuites on
a regular basis so we can push on keeping them running cleanly.  As well
as just the intrisic value of the tests themselves I'd hope that a
visible practical interest would help push more activity in this area.

There's a couple of efforts I'm aware of in this area, hopefully one or
both of them will start delivering.