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