Re: [dpdk-dev] tools brainstorming

["Butler, Siobhan A" <siobhan.a.butler@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, March 20, 2015 2:51 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] tools brainstorming
> 
> 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.
> 
> 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
> 	- abi check (started with validate-abi.sh)
> 	- static analyze (clang, free online coverity)
> 	- comment check (doxygen, codespell, kerspell)
> 	- format check (customized checkpatch)

This is a great list Thomas, totally agree with you we need some guidelines,
and some ways of automating basic checks to catch basic issues,
save time and traffic on the mailing list.

I propose we also add a bug tracking tool (e.g. Bugzilla or other).

And also a standalone page/document/archive of FAQ's.

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