qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/0] .travis and minor compile fixes
Date: Wed, 25 Sep 2013 10:33:12 +0200	[thread overview]
Message-ID: <20130925083312.GC26684@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <p1vc1q1evi.fsf@linaro.org>

On Tue, Sep 24, 2013 at 03:19:29PM +0100, Alex Bennée wrote:
> 
> stefanha@redhat.com writes:
> 
> > On Mon, Sep 23, 2013 at 05:07:27PM +0100, alex.bennee@linaro.org wrote:
> >> Given I found a couple of issues while doing this I think this is
> >> useful alongside the existing buildbot efforts. It allows developers
> >> to run simple smoke-tests without access to the buildbot
> >> infrastructure (but of course needing github/travis access, free for
> >> FLOSS projects).
> <snip>
> > Travis CI allows individual developers to modify the build
> > configuration.  This is much more friendly.
> >
> > Can you explain the limitations of Travis CI?  For example, does it
> > start costing money at some point?
> 
> It is free to all public repositories. There is a "Pro" service which
> allows you to set-up testing on private repos (much like GitHubs model).
> The actual code for Travis is open source
> (https://github.com/travis-ci/travis-ci) although I'm not aware of
> anyone setting up another instance of it. I'm not aware of any plans to
> charge open source projects for it's use.
> 
> The main limitation is the host build VM is Ubuntu 12.04 LTS. I'm not
> sure how much of a limitation this is for the general developer -
> Debian/RPM differences aside I would expect most compile failures to be
> caught regardless of the host.

Hmm...that misses extra bases we cover:

 * Solaris, FreeBSD, Mac OS, etc hosts
 * Stable distros with older library versions (e.g. Red Hat Enterprise
   Linux 5.x)
 * Different gcc versions report different warnings

> I don't think this should attempt to replace other CI efforts. I know
> that Linaro runs some tests through it's LAVA infrastructure and that's
> an area I'm likely to look at expanding. The LAVA infrastructure is more
> suited to testing on non-x86 hardware and running system image/kvm
> integration tests. Having said that I think it can certainly act as a
> good gatekeeper into "master" - if your not passing the Travis tests
> then the branch should probably not be merged.

I would like to replace buildbot because the utility vs maintenance
ratio is too low (but still better than no continuous integration at
all).

The ideal system allows untrusted users to build their own source trees
and make modifications to their build configuration.  That way everyone
is able to take advantage of continuous integration/build farm.

Stefan

  reply	other threads:[~2013-09-25  8:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-23 16:07 [Qemu-devel] [PATCH v2 0/0] .travis and minor compile fixes alex.bennee
2013-09-23 16:07 ` [Qemu-devel] [PATCH 1/3] .travis.yml: basic compile and check recipes alex.bennee
2013-09-23 16:07 ` [Qemu-devel] [PATCH 2/3] .travis.yml: greatly expand the coverage + more builds alex.bennee
2013-09-23 16:07 ` [Qemu-devel] [PATCH 3/3] block/stream.c: ensure copy always set alex.bennee
2013-09-24 12:06   ` Stefan Hajnoczi
2013-09-24 14:27     ` Alex Bennée
2013-09-25  8:41       ` Stefan Hajnoczi
2013-09-24 11:41 ` [Qemu-devel] [PATCH v2 0/0] .travis and minor compile fixes Stefan Hajnoczi
2013-09-24 14:19   ` Alex Bennée
2013-09-25  8:33     ` Stefan Hajnoczi [this message]
2013-09-24 12:07 ` Stefan Hajnoczi

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=20130925083312.GC26684@stefanha-thinkpad.redhat.com \
    --to=stefanha@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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).