Maintaining Activity Packs

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Stone wrote:
|   * to the extent that we are able, we should record the compatibility
|     matrix between builds and activities

Once upon a time, there was going to be a build called "First Release to
Service", and its number was to be 1.
~From http://wiki.laptop.org/go/Activity_bundles:
"Each activity.info file must have a "host_version" key. The version is a
single positive integer. This specifies the version of the Sugar
environment which the activity is compatible with. (fixme: need to specify
sugar versions somewhere. Obviously we start with 1.)"

It seems to me that FRS ~= Update.1.  It's all designed; it just needs to
be implemented (and that's easy).

|   * what assistance are we obligated to provide to deployments?
If OLPC is not completely daft, it must do everything possible to make the
governments happy, so that they are most likely to recommend OLPC to their
neighbors.

|   * if we discover notable flaws (security, legal, "objectionable
|     content") in bundles that a deployment is using, what should we do?
Communication and openness are the hallmarks of OLPC.

|   * in particular, whose responsibility is it to initiate communication
|     of this sort?
What, you don't have a distinct relationship manager responsible for
ensuring complete communication with each client?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH5EPgUJT6e6HFtqQRAgtyAJ9pLkQZZSwjSZjCya67PUqGHqpDpACgmpjv
wpUiyhV4z9aTu1wOc/RbPGk=
=bZuB
-----END PGP SIGNATURE-----