Re: [Ksummit-discuss] [CORE TOPIC] [nomination] Move Fast and Oops Things

[Matt Fleming <matt@console-pimps.org>]

On Wed, 21 May, at 04:55:47PM, Greg KH wrote:
> On Wed, May 21, 2014 at 12:48:48AM -0700, Dan Williams wrote:
> > With regards to saying "no" faster, it seems kernel code rarely comes
> > with tests.  However, maintainers today are already able to reduce the
> > latency to "no" when the 0-day-kbuild robot emits a negative test.
> > Why not arm that system with tests it can autodiscover?  What has held
> > back unit test culture in the kernel?
> 
> The fact that no one has stepped up and taken maintainership of the
> tests and ensure that they continue to work.

That's not usually how unit tests work. They're supposed to be owned by
everyone, i.e. if your change breaks the test you are responsible for
fixing your change, or the test, or both. Everyone needs to ensure the
tests continue to work.

Likewise, the person implementing a new feature is the most well
equipped to write tests for it. Unfortunately that does require a
certain amount of "buy-in" from the community.

However, a maintainer role might make sense for collating test results,
reporting failures or running the tests on a large number of hardware
configurations, like how Fengguang Wu says "The 0-day infrastructure
shows your commit introduced a regression" or Stephen Rothwell says "A
merge of your tree causes these conflicts".

For anything other than trivial cases I wouldn't expect these guys to
have to fixup the breakage to ensure the tests continue working - that
kind of never ending battle would make a person's head explode.

-- 
Matt Fleming, Intel Open Source Technology Center