From: "Simon Kågström" <simon.kagstrom@netinsight.net>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] DPDK: Proposal for a patch patch-test integration tree
Date: Thu, 28 May 2015 08:54:39 +0200 [thread overview]
Message-ID: <5566BBAF.1040408@netinsight.net> (raw)
In-Reply-To: <55662DAF.3000909@redhat.com>
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
next prev parent reply other threads:[~2015-05-28 6:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 20:48 Thomas F Herbert
2015-05-27 21:22 ` Vincent JARDIN
2015-05-28 14:18 ` Thomas F Herbert
[not found] ` <20150527210624.GA15347@mhcomputing.net>
2015-05-27 22:36 ` Thomas F Herbert
2015-05-28 6:54 ` Simon Kågström [this message]
2015-05-28 13:10 ` Wiles, Keith
2015-05-28 9:48 ` Thomas Monjalon
[not found] ` <556728A1.8070403@redhat.com>
2015-05-28 14:44 ` Thomas Monjalon
2015-05-28 15:01 ` Thomas F Herbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5566BBAF.1040408@netinsight.net \
--to=simon.kagstrom@netinsight.net \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).