[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[fluid-dev] Proposal: FluidSynth tester program
From: |
David Henningsson |
Subject: |
[fluid-dev] Proposal: FluidSynth tester program |
Date: |
Wed, 11 Jul 2012 20:57:28 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
Something I've been thinking of for a while, and the recent thread
reminded me of that thought...
FluidSynth is quite a versatile program/library, and we all want
different things out of it. No one of us has the full picture, or uses
FluidSynth to all the different things it can be used for.
Making sure that none of all these use cases break, is one of
FluidSynth's biggest challenges, and maybe sometimes it can cause us to
be overly cautious.
Here's a proposal that might help us with that challenge.
* Before every release, a release candidate tarball will be released.
* You agree to install and test the tarball in the way(s) you have
signed up for. You are also welcome to test the svn trunk, this is
optional but can be very helpful.
* If your test succeeds, you report back on a wiki page we will use to
track tests and testers.
* If your test fails, you both report that on the wiki page, and on
the mailinglist.
* Your benefit will be the fantastic glory of having your name on the
wiki page ;-)
* Your real benefit will be that it will be less likely that
FluidSynth will be buggy for your use case, i e, you - and others who
use FluidSynth in the same way - will be able to upgrade safely.
Obviously we'll try to fix bugs that come up, especially if they are
regressions from a previous version of FluidSynth, but there are no
guarantees given.
The imagination is the limit of tests to choose, but here are some examples:
* Testing that the tarball builds for your favorite operating system
and build environment
* Testing a certain backend driver (jack, alsa, pulseaudio, coreaudio etc)
* Testing that low-latency does not regress, i e, that you can run
without xruns with at least the same latency as you could before.
* Testing a specific program or binding you use together with
FluidSynth (jOrgan, QSynth, SDL bindings, etc etc)
* Testing that "fast render" can still render as fast as it could in
the previous version
* Testing that some soundfont file still renders to the same sounds
(or better)
* Testing the internal midi player (with your favorite song), and/or
sequencer
* etc etc
What do you think? It obviously won't be much of a tester program
without a bunch of testers, so is this anything you think would make so
much sense, that you would be willing to run a test or two yourself?
// David
- [fluid-dev] Proposal: FluidSynth tester program,
David Henningsson <=