Michael,<br>It seems like "recording the compatibility matrix between builds and activities" alone is a 2-3 person job in the very near future. Today it is probably a full time QA person -- and we are short about 3 QA people right now. <br>
<br>It would be great to get some feedback as to how this can be achieved by the developer of the activity -- or what kind of  automated tools can be developed to make it easy to test compatibilty; and how can we encourage people to do this testing. We have to assume that OLPC will NEVER have enough people to do backward compatibility testing for activities, other than a few very basic activities.<br>
<br>Kim<br><br><br><div class="gmail_quote">On Fri, Mar 21, 2008 at 7:25 PM, Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="Ih2E3d"><br>
Michael Stone wrote:<br>
|   * to the extent that we are able, we should record the compatibility<br>
|     matrix between builds and activities<br>
<br>
</div>Once upon a time, there was going to be a build called "First Release to<br>
Service", and its number was to be 1.<br>
~From <a href="http://wiki.laptop.org/go/Activity_bundles" target="_blank">http://wiki.laptop.org/go/Activity_bundles</a>:<br>
"Each <a href="http://activity.info" target="_blank">activity.info</a> file must have a "host_version" key. The version is a<br>
single positive integer. This specifies the version of the Sugar<br>
environment which the activity is compatible with. (fixme: need to specify<br>
sugar versions somewhere. Obviously we start with 1.)"<br>
<br>
It seems to me that FRS ~= Update.1.  It's all designed; it just needs to<br>
be implemented (and that's easy).<br>
<div class="Ih2E3d"><br>
|   * what assistance are we obligated to provide to deployments?<br>
</div>If OLPC is not completely daft, it must do everything possible to make the<br>
governments happy, so that they are most likely to recommend OLPC to their<br>
neighbors.<br>
<div class="Ih2E3d"><br>
|   * if we discover notable flaws (security, legal, "objectionable<br>
|     content") in bundles that a deployment is using, what should we do?<br>
</div>Communication and openness are the hallmarks of OLPC.<br>
<div class="Ih2E3d"><br>
|   * in particular, whose responsibility is it to initiate communication<br>
|     of this sort?<br>
</div>What, you don't have a distinct relationship manager responsible for<br>
ensuring complete communication with each client?<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.7 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a><br>
<br>
iD8DBQFH5EPgUJT6e6HFtqQRAgtyAJ9pLkQZZSwjSZjCya67PUqGHqpDpACgmpjv<br>
wpUiyhV4z9aTu1wOc/RbPGk=<br>
=bZuB<br>
-----END PGP SIGNATURE-----<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br>