Re: [dpdk-dev] DPDK: Proposal for a patch patch-test integration tree

["Wiles, Keith" <keith.wiles@intel.com>]

On 5/28/15, 1:54 AM, "Simon Kågström" <simon.kagstrom@netinsight.net>
wrote:

>I spot a can of worms to be opened here :-)
>
>On 2015-05-27 22:48, Thomas F Herbert wrote:
>> Work Flow and Process:
>> 
>> All patches will be taken from from public submissions to dpdk-dev.org
>> scraped from dpdk patchwork. Patches will be applied to the patch-test
>> tree and tested against HEAD as they are received. The feedback from the
>> testing will be provided to the community. The patch-test tree will
>> periodically be git pull'ed from dpdk.
>> 
>> Longer term goal:
>> 
>> Initially, the patches will be applied along with some simple smoke
>> tests. The longer term goal is to automate this process, apply more
>> extensive tests and post the results in dpdk patchwork,
>> http://dpdk.org/dev/patchwork/project/dpdk/list/ which would have an
>> accompanying mailing list for distribution of a results summary of the
>> tests.
>
>Actually, github and services such as travis-ci and coveralls already
>provide this functionality (with very little setup). So when someone
>sends a pull request, the continuous integration service travis-ci will
>notice it, and start a build and (possibly) run a test suite on the code
>- with the patches applied.
>
>If code coverage is collected in the process [1], it's uploaded to the
>coveralls site. Both travis-ci and coveralls will add a note to the pull
>request saying something like "Build failed with this patch, be careful"
>or "Build OK, everything is fine" and "Coverage decreased with 5% with
>this patch" etc etc.
>
>Of course, github provides an API so it's entirely possible to add your
>own continuous integration support with the same functionality as
>travis-ci (customized for DPDK).
>
>
>
>So before venturing into implementing something like this, I think the
>DPDK project should at least consider the existing alternatives.

Using the above process seems very reasonable and we already have github
account we can mirror the code and run these processes. This gives us a
more standard method instead of a home grown method, but as Simon states
we could enhance the process via the API.

I may have bruised a few worms here, so very sorry :-)
>
>And with that, I close the can of worms again. I hope no worms were hurt
>in the process! :-)
>
>// Simon
>
>[1] https://github.com/SimonKagstrom/kcov - yes my personal project