From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Butler, Siobhan A" Subject: Re: tools brainstorming Date: Fri, 20 Mar 2015 15:07:29 +0000 Message-ID: <0C5AFCA4B3408848ADF2A3073F7D8CC86D53E553@IRSMSX109.ger.corp.intel.com> References: <3571725.20GtF5MAnU@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: Thomas Monjalon , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: <3571725.20GtF5MAnU@xps13> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" > -----Original Message----- > From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Thomas Monjalon > Sent: Friday, March 20, 2015 2:51 PM > To: dev-VfR2kkLFssw@public.gmane.org > Subject: [dpdk-dev] tools brainstorming >=20 > Hi, >=20 > As you probably know, a MAINTAINERS file is being filled, which is a grea= t > help to request patch reviews and discuss design with the knowledgeable > people of this young DPDK community: > http://dpdk.org/browse/dpdk/tree/MAINTAINERS >=20 > The next step is to clearly define what are the guidelines to review a pa= tch > and accept it. So let's write a new document CONTRIBUTING (or another > capitalized file ;). It will help contributors to do the right checks bef= ore > submitting, and will help reviewers. >=20 > 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. >=20 > 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. >=20 > At the end, we should be able to pass a "make check" on the whole code an= d > a "make checkpatch" before submitting. > Then the result of these tools could be automatically checked and display= ed > 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. >=20 > Comments and contributions are more than welcome!