[Sugar-devel] Activity updates

[Aleksey Lim]

On Tue, Oct 19, 2010 at 07:28:45PM -0200, Bernie Innocenti wrote:
> Quoting you from IRC:
> 
> <garycmartin> 09:36:21> bernie: Was it you that mentioned that
> deployments did not want to point to ASLO for update as version were not
> being flagged correctly for Sugar release compatibility?
> <garycmartin> 09:45:09> bernie: FWIW, I've just been through 60+
> activities testing ASLO installs on a clean XO-1 0.82 build (0.84 is
> next on my todo list). I only found 4 activities that didn't have an old
> enough past version uploaded for that release of Sugar, and only one
> activity that failed to launch due to a trivial file permission error in
> the bundle (SL#2464).
> 
> 
> Indeed, almost all activities are compatible across 0.84-0.88. Probably
> also 0.90.
> 
> But the point is that deployments really need to ensure that the
> activity works with their lesson plans. For example, Turtle Art's
> sensors support has been broken for a while in ASLO.
> 
> At any time someone could upload a new version of an activity that
> breaks some feature that deployments were relying upon. Without
> interposing an interim QA stage, possibly done by the deployment's
> education team, ASLO cannot be relied upon for updates.

> My proposed solution consits in reviving the microformat protocol for
> activity updating (already done by Anish) and then augment the existing
> concept of "collections" in ASLO to let deployments specify a particular
> bundle version.

Just a couple of problem that can't be solved in such way:

* problem is not only in activities itself but also in dependencies
  (some sugar distributions might have them but other don't)
  the only way for ASLO is bundling them all

* binary based activities that are strictly depends on particular distro
  version (eg TuxPaint being built against fc9 crashes on fc9+updates)
  it is nightmare to try cover such questions on ASLO

* collections are more users' method, so if one user decided to create
  new collection, he will break any QA efforts because can add arbitrary
  activity/version

The way I have in mind is using Bazaar to cover all technical questions
(development and QA related) and keep ASLO as a frontend for Bazaar
packages.

At the end, ASLO might have all activities hosted on Bazaar
(for effectively solving issues w/ dependencies and binaries). Each ASLO
activity will have a source, i.e., Bazaar project.

(We should have a possibility to have bunch of versions of the same
activity at the same time, eg, results of experiments of doers.)

So, users can filter all activities (not only in plain list but in their
collections as well) by source project. If sugar deployment created
"New Deployment" project on Bazaar and linked/branched/created-new
activities there, all their users can download only these activities
(if they want to get QAed stuff).

-- 
Aleksey