Some thought regarding the testing process.<div><br></div><div>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.</div>

<div><br></div><div>The number of testers required for this is probably larger than what you can recruit through the ScummVM forums.<br clear="all"><br></div><div>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.</div>

<div><br></div><div>Would it be feasible?</div><div>_______________________<br>Pierre-Yves Gérardy, MD<br>Headache Research Unit<br>University of Liege<br>Citadelle Hospital (University dept. of Neurology),<br>Boulevard du XIIe de Ligne, 1<br>

B4000 Liège, Belgium<br>Phone : +32 (0) 4 225 71 41<br>Mobile : +32 (0) 472 543 727<br>Fax : +32 (0) 4 223 88 07<br>Department Secretary : Ms Groven : +32 (0) 4 225 63 91<br>
<br><br><div class="gmail_quote">2009/7/16 Pierre-Yves Gérardy <span dir="ltr"><<a href="mailto:pygy79@gmail.com">pygy79@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Well, actually, Courgette is not out yet... They only provide a high level description.<br clear="all">_______________________<br>Pierre-Yves Gérardy, MD<br>Headache Research Unit<br>University of Liege<br>Citadelle Hospital (University dept. of Neurology),<br>


Boulevard du XIIe de Ligne, 1<br>B4000 Liège, Belgium<br>Phone : +32 (0) 4 225 71 41<br>Mobile : +32 (0) 472 543 727<br>Fax : +32 (0) 4 223 88 07<br>Department Secretary : Ms Groven : +32 (0) 4 225 63 91<br>
<br><br><div class="gmail_quote">2009/7/16 Pierre-Yves Gérardy <span dir="ltr"><<a href="mailto:pygy79@gmail.com" target="_blank">pygy79@gmail.com</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe we can come up with a way to store these nightlies efficiently<br>
(maybe using a binary diff approach, i.e., only store a binary diff<br>
between builds; of course then one would need an efficient retrieval<br>
system, too). But I think it's too far outside our scope to work on<br>
something like this, so unless there is an off-the-shelf solution, I'd<br>
not bother with it.</blockquote><div><br></div></div><div>For the binary diff side of the equation Google's Courgette just got out.</div><div><br></div><div>For the retrieval system, you could use a binary-partition based system too (ie store daily, 2-daily, 4daily etc diffs)...</div>



<div><br></div><div><br></div><div><a href="http://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html" target="_blank">http://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html </a></div></div><a href="http://dev.chromium.org/developers/design-documents/software-updates-courgette" target="_blank">http://dev.chromium.org/developers/design-documents/software-updates-courgette</a>
</blockquote></div></div></div><br>
</blockquote></div><br></div>