[Sugar-devel] ASLO QA process

[Aleksey Lim]

On Thu, Apr 29, 2010 at 08:46:06AM -0400, Bernie Innocenti wrote:
> El Sat, 24-04-2010 a las 07:19 +0000, Aleksey Lim escribió:
> > In my mind activities on ASLO are not something like packages in regular
> > GNU/Linux distribution. ASLO is not one centralized product, as already
> > was mentioned several times it is (or should) palace to share your work
> > (maybe in trash) with others thus we (will)have bunch of outdated/
> > forgotten projects. And it is ok for sugar (but not for GNU/Linux
> > distributions).
> 
> I also intended ASLO this way, until I realized that builds are being
> composed by picking the latest versions of activities from ASLO
> directly. Same goes for the update control panel.
> 
> Because of this, users expect the things they find on ASLO to actually
> work and get pissed off if a new version of an activity breaks horribly.
> 
> Distributors (like Paraguay Educa and OLPC) need to introduce a QA layer
> somewhere between the activity authors and the users. Whether we thought
> it this way or not, bundles on ASLO are equivalent to distro packages.

There are no doubts that distributors need/should-have such QA layer.
The thing is that we need(imho) free style sharing repository as well.

For now, ASLO is being used in both ways:

* repository in distro meaning since there is Control Panel updater
  - but it will fetch any version from ASLO w/o QA
  - but having regular QA team on ASLO will make it like a regular
    linux distribution w/ all related issues including loosing free
    style repo meaning

* free style repo
 - but such activities are marked as experimental versions that could
   not be correct
 - users need to be logged in to download these activities
 - ASLO doesn't support forks

So, ASLO is not successful in both ways.

> > And also most of activities come from individuals i.e. it's their
> > masterpieces. So, lets talking about "forking" not about "taking over".
> 
> Ok, but we need to make sure that there's a way for one of these forks
> to become an automatic update for an abandoned activity.
> 
> Moreover, there's the question of finding good names for activities.
> If the maintainer of Browse disappears, I wouldn't want to tell users:
> "now you should download BernieBrowse instead of Browse".

Well, with current AMO, we have to do something similar (until someone
will implement all features sugar needs in ASLO).

> > In my mind instead of increasing level of bureaucracy in sugar, for now,
> > we could ping authors/nd publish forks on ASLO (with new bundle_id) and
> > start implementing new Activities Library with taking into account all
> > sugar specific (ASLO in case of AMO is not such, since Mozilla controls
> > AMO addons and it is mostly centralized repo w/ QA etc).
> 
> I agree with you that we should keep bureaucracy to a minimum.
> 
> I liked your proposal of creating per-deployment collections to manage a
> set of activities that has been tested and approved. I think this is one
> of the things Uruguay wanted.
> 
> If we decided to go this path, what would be missing? Does our update
> API support collections? Can anyone create a collection easily?

AMO doesn't support such feature by design (since there is only one
deployment for addons) but I think it could be implemented in simple
manner.

* mention particular versions while adding activities to collection
* support collections in API updater, so users will fetch updates not
  from full ASLO but from particular collection
* anyone create collections and add users who can edit them, but we can
  add ASLO groups for particular collection to make users management
  more effective

All these steps are pretty doable.

> > I'm working on Activities Library (on early stage). It will look
> > like:
> > 
> > * server in the person of buddy in F1 view with shared instance of
> >   Library activity
> > * any user can join this instance to see what activities are on
> >   the server
> > * can just click to launch
> > * can share new activity or fork of existed
> > * any user can be such server, he just need to follow regular sugar
> >   practice, create new instance of Library and share it
> > 
> > Any ideas are welcome
> > http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library
> 
> Fantastic project!
> 
> Will it support multiple libraries, for the same of decentralizing
> things?
> 
> I can imagine that many deployments would want a hierarchical thing to
> save bandwidth and delegate decisions to school principals: the
> schoolserver would be the first place where children search for
> activities, then would come the deployment server and lastly ASLO.

Thanks, this hierarchical structure will be useful not only on pure
server side but on peers side as well, like:

* someone added bunch of cool activities to his list (w/o
  downloading|launching them)
* shares his Activity_Library instance
* any joined user can see|download|launch these activities

> 
> I think dsd did something like this for the old updater.
> 
> -- 
>    // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
> 

-- 
Aleksey