Re: Maintaining Activity Packs
Michael, 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. 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. Kim On Fri, Mar 21, 2008 at 7:25 PM, Benjamin M. Schwartz < [EMAIL PROTECTED]> wrote: > -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- > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Maintaining Activity Packs
-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- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Maintaining Activity Packs
Dear devel, While drafting release notes for Update.1 RC2 (signed update.1-699), we realized that we need a good story about what we want the ecosystem of activity and library packs (for use with the customization key [1]) to be. The rough sense emerging from the folks I've interviewed so far (dgilmore, kimquirk, walter, cjb) is that: * activity packs are collections maintained by public maintainers * people running deployments are responsible for choosing activities that work for them and we should assist in this process * for the moment, any activity packs that we provide are just conveniences and advice to them on how to get started * however, we should do our best to keep authoritative versions of all activities we encounter and to encourage other folks to mirror this content * to the extent that we are able, we should record the compatibility matrix between builds and activities However, there are several questions that these rough thoughts do not yet address: * what assistance are we obligated to provide to deployments? * if we discover notable flaws (security, legal, "objectionable content") in bundles that a deployment is using, what should we do? * in particular, whose responsibility is it to initiate communication of this sort? * (and others not listed here) Thoughts? Michael [1]: http://wiki.laptop.org/go/Customization_key ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
