[Sugar-devel] ASLO QA process

[Aleksey Lim]

On Thu, Apr 29, 2010 at 06:35:03AM -0700, Thomas C Gilliard wrote:
> 
> 
> 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.
> >
> >   
> Some random thoughts:
> 
> 1-)
> Is there no way to detect the requesting hardware and deployment first 
> and then
> have ASLO filter the appropriate applications for download?

Sounds pretty undoable, but maybe it is not... Anyway ASLO operates only
in terms of Sugar Platform versions
http://wiki.sugarlabs.org/go/0.86/Platform_Components

> 2-)
> An INDEXED rpm depository to install from, or Download from would be 
> nice for advanced users.

update-aslo script could be used in such manner
http://activities.sugarlabs.org/services/update-aslo.php?id=usbcreator
where id is bundle_id, this php returns detailed info about recent activity
versions including file to download.

> 3-)
> I have a CD Image of 111 .xo activities for Download from:
> http://people.sugarlabs.org/Tgillard/ASLO.iso
> for drag-drop "sneaker-net" installs.
> Maybe a down-loadable set of these CD Images should be maintained for 
> different deployments and hardware.
> (this would also save a lot of server usage)
> > 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.
> >
> >
> >   
> >> 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".
> >
> >
> >   
> >> 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?
> >
> >
> >   
> >> 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.
> >
> > I think dsd did something like this for the old updater.
> >
> >   

-- 
Aleksey