Re: [dpdk-dev] tools brainstorming

[Neil Horman <nhorman@tuxdriver.com>]

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!
>