Walter wrote: >> I think we need to decouple the release cycles between activities and >> Sugar to whatever degree possible. Activities should be able to change >> at whatever pace is dictated by the activity developers. Since >> activities depend upon Sugar, the Sugar schedule needs to be more >> predictable. The only time it seems there would be a conflict is when >> an incompatible change in a Sugar module is made
Yep. When the decision was made to not deliver built-in activities within the laptop.org builds, Activities development was decoupled from Sugar (except as noted above). Regarding the "schedule" for the 'release' of Activities: I believe there are three populations of Activity-users to be kept in mind: 1) Users who will not upgrade their Activities except under the direction of whoever they got their OLPCs from. [I presume this is what the "automatic_upgrade" (e.g., 'security/update-stream') was designed for. How Activities are submitted (including timeline determination) to this facility needs to be documented.] (2) Users who don't want to wait for an "automatic_upgrade", but who would only accept __certified__ Activities. [I presume that when enough "significant" new/changed Activities have been tested by a responsible organization, that organization will create a newer version of an "activity package", and make that package available on a server. This can be need-driven, instead of time-driven.] (3) Users who would like to independently install Activities, even when such Activities have not undergone "official" QA. [I presume that a "master list" of the latest and greatest Activities will be kept by a responsible organization. Activities ought to be listed as soon as the individual developer says so.] -------- If "doesn't run" situations are to be avoided, something like a "package manager" will have to be provided AT EACH XO (to perform the *actual* Activity installation). It will check the system for pre-requisites as indicated by each Activity, and will alert the user when an install is attempted whose pre-requisites are not met. mikus _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
