From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 5935E569C for ; Fri, 20 Mar 2015 16:16:09 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YYyeb-0007JC-HL; Fri, 20 Mar 2015 11:16:08 -0400 Date: Fri, 20 Mar 2015 11:16:04 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20150320151604.GB19548@hmsreliant.think-freely.org> References: <3571725.20GtF5MAnU@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3571725.20GtF5MAnU@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] tools brainstorming X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:16:09 -0000 On Fri, Mar 20, 2015 at 03:51:11PM +0100, Thomas Monjalon wrote: > Hi, > > As you probably know, a MAINTAINERS file is being filled, which is a great > help to request patch reviews and discuss design with the knowledgeable people > of this young DPDK community: > http://dpdk.org/browse/dpdk/tree/MAINTAINERS > > The next step is to clearly define what are the guidelines to review a patch > and accept it. So let's write a new document CONTRIBUTING (or another > capitalized file ;). It will help contributors to do the right checks > before submitting, and will help reviewers. > +100. This is a great idea. A few thoughts. > As we are lazy developers, writing guidelines is not enough. It must be > coupled with the integration of some tools. Let's work on these ones: > - make autotests easier and faster to run for smoke testing > - automated basic testpmd check > - build check with various options combinations The kernel does this with some special make targets (make allyesconfig, make randconfig, etc). They basically act as build time fuzzers and are very useful. I'm not sure that the DPDK build system is really condusive to that yet though, since its made up of static configuration files. This may require some build environment changes > - abi check (started with validate-abi.sh) This will need continued improvement, as it is currently a very interactive tool. I'm not sure that in its current for it will ever be fully automated, save for perhaps being able to give you a boolean response (yes, ABI is compatible, or no it is not). > - static analyze (clang, free online coverity) > - comment check (doxygen, codespell, kerspell) > - format check (customized checkpatch) > > I'm sure this last item will trigger a lot of debate. > Actually, format checking can be of two kinds: > - commit message formatting (how to write the title, how and when adding > Fixes tag, Signed-off-by tag, etc); > - coding style might deserve its own document. > I think both of these are worthwhile, especially if their not too egregious in terms of work overhead. A coding style is pretty common to enforce. Commit messages are a bit less so, but it would be reasonable to do some simple things, like add a subsystem tag, signed off line, etc > At the end, we should be able to pass a "make check" on the whole code and > a "make checkpatch" before submitting. > Then the result of these tools could be automatically checked and displayed > in patchwork or in an adapted version of qemu's patchew. But this is > obviously a later step. > When all automatic lights are green and human design review is properly done, > the patch can be acknowledged by one or many reviewers. Speaking about that, > it would be helpful to have a column in our patchwork to summarize the counts > of tests, reviews and acknowledgements. > > Comments and contributions are more than welcome! >