[Sugar-devel] ASLO QA process

[Thomas C Gilliard]

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?

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

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/0d8a316f/attachment.htm