[sugar] Release schedule and process

[Mikus Grinbergs]

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