From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id A579F379E for ; Mon, 23 Mar 2015 09:42:13 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 23 Mar 2015 01:42:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,451,1422950400"; d="scan'208";a="702688131" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by orsmga002.jf.intel.com with ESMTP; 23 Mar 2015 01:42:11 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 23 Mar 2015 16:41:54 +0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.108]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.149]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 16:41:47 +0800 From: "Cao, Waterman" To: Thomas Monjalon , "dev@dpdk.org" Thread-Topic: [dpdk-dev] tools brainstorming Thread-Index: AQHQYx2Dni6s1B1BNUyqjFN9nAaNCg== Date: Mon, 23 Mar 2015 08:41:47 +0000 Message-ID: References: <3571725.20GtF5MAnU@xps13> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 23 Mar 2015 08:42:14 -0000 On 2015/3/20 22:52, Thomas Monjalon wrote:=0A= > Hi,=0A= >=0A= > As you probably know, a MAINTAINERS file is being filled, which is a grea= t=0A= > help to request patch reviews and discuss design with the knowledgeable p= eople=0A= > of this young DPDK community:=0A= > http://dpdk.org/browse/dpdk/tree/MAINTAINERS=0A= >=0A= > The next step is to clearly define what are the guidelines to review a pa= tch=0A= > and accept it. So let's write a new document CONTRIBUTING (or another=0A= > capitalized file ;). It will help contributors to do the right checks=0A= > before submitting, and will help reviewers.=0A= >=0A= > As we are lazy developers, writing guidelines is not enough. It must be= =0A= > coupled with the integration of some tools. Let's work on these ones:=0A= > - make autotests easier and faster to run for smoke testing=0A= > - automated basic testpmd check=0A= > - build check with various options combinations=0A= > - abi check (started with validate-abi.sh)=0A= > - static analyze (clang, free online coverity)=0A= > - comment check (doxygen, codespell, kerspell)=0A= > - format check (customized checkpatch)=0A= >=0A= > I'm sure this last item will trigger a lot of debate.=0A= > Actually, format checking can be of two kinds:=0A= > - commit message formatting (how to write the title, how and when adding= =0A= > Fixes tag, Signed-off-by tag, etc);=0A= > - coding style might deserve its own document.=0A= >=0A= > At the end, we should be able to pass a "make check" on the whole code an= d=0A= > a "make checkpatch" before submitting.=0A= > Then the result of these tools could be automatically checked and display= ed=0A= > in patchwork or in an adapted version of qemu's patchew. But this is=0A= > obviously a later step.=0A= > When all automatic lights are green and human design review is properly d= one,=0A= > the patch can be acknowledged by one or many reviewers. Speaking about th= at,=0A= > it would be helpful to have a column in our patchwork to summarize the co= unts=0A= > of tests, reviews and acknowledgements.=0A= >=0A= > Comments and contributions are more than welcome!=0A= >=0A= Hi Thomas,=0A= =0A= That's good idea to check patch before merging it into branch.=0A= We can perform basic test per each patch and improve the quality of=0A= patch.=0A= =0A= As you knew, currently Intel DPDK test team maintained automation=0A= test tool to perform build check and smoke test on a lot of mainstream=0A= platforms.=0A= It will a good chance to share these knowledge with whole DPDK=0A= community.=0A= =0A= - Daily Build Test=0A= So far, Intel test team run daily build test on CentOS6.5, Fedora=0A= 18/20/21, RedHat 6.5/7.0, SUSE 11 SP2/SP3, Ubuntu 12/14, Oracle Linux=0A= 6.4 and FreeBSD 10.=0A= In addition, we also verified with different compilers, kernels and=0A= DPDK build options.=0A= Since Our daily build test is focus on master branch and only=0A= monitor latest code changes.=0A= Maybe we don't need to check so much OS per each patch, just make=0A= quick build check with short list.=0A= We can share our build script with contributors/maintainer. they=0A= can use it to verify their patch set.=0A= =0A= - Automated Smoke Test=0A= Based on DTS (DPDK test suite), we already built up automated smoke=0A= test on FC16/18/20/21/ , Ubuntu and Redhat. it's composed of unit test=0A= and function test for dpdk sample application.=0A= I think that it's easy to build up automated smoke test based on=0A= patch, we just need to define which test cases should include in the=0A= list, and make sure if it can achieve at shortest time.=0A= =0A= - Bug Tracking=0A= During our test cycle, we found some defects in release candidates. =0A= But it's difficult to track/report them without public bug tool.=0A= It's really helpful to get one formal tool to manage these=0A= information and speed up bug fixing.=0A= =0A= In addition, I think that patchwork is a good tool, which provides a=0A= place to show test result for each patch.=0A= But patchwork is focus on patch level, we need to think how to test=0A= latest code branch in package level.=0A= Finally, we are eager to share our experience of validation with DPDK=0A= community.=0A= We would like to contribute tool and script, and help to improve=0A= quality of DPDK release.=0A= =0A= regards=0A= =0A= Waterman=0A= =0A= =0A=