From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Suggestion for testing framework
Date: Wed, 04 Jun 2008 12:36:25 +0200 [thread overview]
Message-ID: <48467029.5040707@bellard.org> (raw)
In-Reply-To: <767386.58386.qm@web57006.mail.re3.yahoo.com>
Balazs Attila-Mihaly (Cd-MaN) wrote:
> Hello all
>
> It seems that there is agreement that some sort of automated testing
> is "a good thing" ;-). I'll have some free time in the next couple of
> days and plan on throwing something like this together on a spare
> box. I was thinking along the lines:
>
> - several qemu images (one with Debian, one with Windows XP - I can
> get a free student license for it, etc) - a script does a checkout of
> the trunk, checks if the version number is different from the last
> checkout (to avoid spamming the list :-)) - the script introduces the
> source in each VM, starts the VM and lets the different compilers
> available in the VM (like gcc 3.3, 3.4, mingw) compile the source -
> if the compile fails, it collects the error logs - if the compile
> succeeds, performance and functionality tests are run with the
> resulting binary - the is the most nebulous part for the moment for
> me - if I recall Fabrice said that compiling something inside a VM is
> a good performance test... - results are sumitted to the list - if
> you are ok with that, I wouldn't want to spam the list
>
> Please comment if you find the testing methodology good and what
> performance and functionality test should the process include...
I want to do such automated testing and performance measurements since a
long time, but never found the time to do them. My idea was close to
what you suggest, i.e:
Every day:
- do a checkout
- compile all the versions on i386 and x86_64
- publish the binary packages
- run the linux-user tests with the user emulators
- run some of the disk images with the system emulators.
- run benchmarks (gcc compilation, nbench)
- install and test some commercial OSes (this part cannot be
redistributed of course)
The results should be published on a web site, not on the mailing list.
Fabrice.
next prev parent reply other threads:[~2008-06-04 10:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-03 20:59 [Qemu-devel] Suggestion for testing framework Balazs Attila-Mihaly (Cd-MaN)
2008-06-03 21:50 ` Erik de Castro Lopo
2008-06-03 21:53 ` Anthony Liguori
2008-06-03 22:02 ` Paul Brook
2008-06-03 22:05 ` Glauber Costa
2008-06-03 22:17 ` Anthony Liguori
2008-06-03 22:25 ` Paul Brook
2008-06-03 22:35 ` Thiemo Seufer
2008-06-04 6:41 ` Laurent Desnogues
2008-06-04 7:49 ` Laurent Desnogues
2008-06-04 9:44 ` Edgar E. Iglesias
2008-06-04 10:28 ` Avi Kivity
2008-06-04 12:32 ` Glauber Costa
2008-06-04 12:36 ` Avi Kivity
2008-06-05 10:13 ` Ian Jackson
2008-06-05 12:42 ` Avi Kivity
2008-06-04 10:36 ` Fabrice Bellard [this message]
2008-06-15 18:52 ` [Qemu-devel][Patch] " Stefan Weil
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=48467029.5040707@bellard.org \
--to=fabrice@bellard.org \
--cc=qemu-devel@nongnu.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).