[Scummvm-devel] Bring testers to the team?

Pierre-Yves Gérardy pygy79 at gmail.com
Thu Jul 23 09:56:51 CEST 2009


Some thought regarding the testing process.
There are at the moment 130 games or game paths (counting 5 for MM and 3 for
Indy4) to test, twice, and it's going to explode once more when SCI becomes
supported.

The number of testers required for this is probably larger than what you can
recruit through the ScummVM forums.

Obviously, the solution to minimize the testing load would be to organize
the development process in order to prevent the introduction of regressions
in games whose code didn't change since the last release, in other words, to
freeze the ScummVM core as much as possible, and build on that until it's
not possible to do so otherwise.

Would it be feasible?
_______________________
Pierre-Yves Gérardy, MD
Headache Research Unit
University of Liege
Citadelle Hospital (University dept. of Neurology),
Boulevard du XIIe de Ligne, 1
B4000 Liège, Belgium
Phone : +32 (0) 4 225 71 41
Mobile : +32 (0) 472 543 727
Fax : +32 (0) 4 223 88 07
Department Secretary : Ms Groven : +32 (0) 4 225 63 91


2009/7/16 Pierre-Yves Gérardy <pygy79 at gmail.com>

> Well, actually, Courgette is not out yet... They only provide a high level
> description.
> _______________________
> Pierre-Yves Gérardy, MD
> Headache Research Unit
> University of Liege
> Citadelle Hospital (University dept. of Neurology),
> Boulevard du XIIe de Ligne, 1
> B4000 Liège, Belgium
> Phone : +32 (0) 4 225 71 41
> Mobile : +32 (0) 472 543 727
> Fax : +32 (0) 4 223 88 07
> Department Secretary : Ms Groven : +32 (0) 4 225 63 91
>
>
> 2009/7/16 Pierre-Yves Gérardy <pygy79 at gmail.com>
>
> Maybe we can come up with a way to store these nightlies efficiently
>>> (maybe using a binary diff approach, i.e., only store a binary diff
>>> between builds; of course then one would need an efficient retrieval
>>> system, too). But I think it's too far outside our scope to work on
>>> something like this, so unless there is an off-the-shelf solution, I'd
>>> not bother with it.
>>
>>
>> For the binary diff side of the equation Google's Courgette just got out.
>>
>> For the retrieval system, you could use a binary-partition based system
>> too (ie store daily, 2-daily, 4daily etc diffs)...
>>
>>
>> http://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html <http://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html>
>>
>> http://dev.chromium.org/developers/design-documents/software-updates-courgette
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090723/bad6e745/attachment.html>


More information about the Scummvm-devel mailing list