[Sugar-devel] ASLO QA process

[Thomas C Gilliard]

Aleksey Lim wrote:
> 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
>
>   
Could the  installed start page listing on sugar browse/Activities be 
customized for each version of sugar to link
to a slightly page on ASLO which has the appropriate activities and 
languages depending on the version of sugar, hardware  and deployment.

Or could these be selected from a ASLO start up page prior to access to 
the listings and search page?

Or both

(The XO-1 does have a different activity and update system)
>> 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.
>>>
>>>   
>>>       
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100429/db7432ae/attachment.htm