2009/6/28 Siarhei Siamashka <siarhei.siamashka at gmail.com>
> The one thing that worries me a bit is that apparently (almost) nobody else is
> using 'scaling-test' program. As limited as it is, it could have prevented a
> handful of broken commits already. And you can't rely on me monitoring this
> mailing list forever, effectively working as a trained monkey who just runs
> the test program occasionally and complains when something gets obviously
> broken.
I'm sure nobody is asking you to do that?-)
> Seriously, should we add some 'make test' target with an easily
> interpretable result and ask commiters to reject any patches which make it
> fail unless this failure is investigated and properly explained?
That would be nice, but at least it seems that scaling-test as it is
can't be used in such target.
A quick look in it tells me to just run it, but when I do it says that
it fails. On x86 with and without all optimizations. I tried with
master, 0.15.14, 0.15.12 and 0.14.0. Of these the two first ones say
that it fails and the two others crash.
A longer look tells me that I should compile static binaries and run
the ruby script that figures out which test failed. If I actually had
some code to contribute, this is probably the point where rather than
installing ruby and building static binaries I'd just submit the patch
and hope for the best.
This is of course a sort of blind-testing, I didn't take time to
actually find out how the tool works or anything. Which is the way I'd
expect most contributors to behave, so maybe that's why the tool is
not used more widely.
To make the scaling test useful for such reviewing purposes, it
probably needs first to work without reference binaries (make test
recompiling the library twice sounds like a difficult thing to
achieve), maybe by just accepting the CRC on the command line? That
way you could just run the reference once and store the CRC (unless I
don't understand how the tool works).
Also, the ruby script would be nice to rewrite in sh or some other
more widespread language (it looks trivial enough anyway).
And to make it git-bisect friendly (when/if it can be expected to just
be run and to give a meaningful result), it should return with a
non-zero value on failures.
--
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
See also http://syslog.movial.fi