From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id AAE7B8FA for ; Wed, 21 May 2014 07:56:01 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 244B31F90C for ; Wed, 21 May 2014 07:56:01 +0000 (UTC) Date: Wed, 21 May 2014 16:55:47 +0900 From: Greg KH To: Dan Williams Message-ID: <20140521075547.GA20121@kroah.com> References: <20140516125611.06633446@notabene.brown> <537628ED.1020208@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] [nomination] Move Fast and Oops Things List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. I'm working on solving that issue, by getting funding for someone to do this and focus on tests that all developers and maintainers can use to help ensure that nothing broke when they make a change. Give me a few months, hopefully there will be something I can talk about soon in this area. thanks, greg k-h