[SoaS] Sugar Creation Kit review for inclusion in SoaS

[Thomas C Gilliard]

Aleksey:

I present data from tests of mirabelle 0.88.0 and f14 rawhide 0.88.1 USB 
sticks vs applications.
3 ways:

1- applications shipped on iso
2-yum install sugar* -rpms (41 file install)
3-from 140+ .xo files :

(http://people.sugarlabs.org/Tgillard/ASLOxo-2+ss.tar.bz2)

these .xo were from ASLO copied onto a 1 GB usb stick-

  Ran them from this 2nd stick in a booted Soas Nightly Composes xxxx611

I previously tested with a Mirabelle USB, so I include that data also on 
this spreadsheet:

http://people.sugarlabs.org/Tgillard/Activities-Index-ASLO-f13-Mirabelle-f14-rawhide-Soas-tests.ods

Not a complete test but shows which applications start and stop and have 
preliminary functions
in 0.88.x

Tom Gilliard
satellit

On 06/10/2010 07:01 AM, Aleksey Lim wrote:
> On Wed, Jun 09, 2010 at 08:32:40AM -0700, Thomas C Gilliard wrote:
>    
>> Peter Robinson wrote:
>>      
>>> * 140 Activities
>>> - No QA. The reason we cut down the Activities is Mirabelle was the
>>> ability to provide well tested working Activities. The issue with Read
>>> proves we had trouble dealing with 10. Doing that with 140+ isn't
>>> sustainable.
>>> - There's no guarantee of the license. We only want to ship free ones.
>>> No flash. No Codecs etc.
>>> - Binary inclusions. Support issues on the current SoaS release. It
>>> causes problems and its hard to QA. See point above.
>>> - Its out of date the moment you ship it
>>>
>>>
>>>        
>> *I can make a smaller subset of ASLOxo that covers Mirabelle Compatible
>> Applications.
>> http://people.sugarlabs.org/Tgillard/Activities-Index-Mirabell.ods
>> was a first attempt at doing this.
>> I have been editing the ASLO listings based on this testing.
>>
>> *I think ASLO site has to be changed to recognize
>> what version of sugar is requesting .xo downloads and not permit access
>> to those not compatible.
>> (restricted to password access -experimental)
>>      
> ASLO from beginning (at least in my mind) was a tool for "doer<->doer"
> scheme not for "developer<->deployment/QA<->user". Thus, reviewing while
> making activities public from experimental was/is pretty weak[1].
>
> I'm planing to start changing ASLO code base next week to somehow fix
> this issue. Dunno how it would be, maybe per deployment profile to let
> QA from particular deployment choose what activities/versions work fine
> in their environments. Later, users from this deployment (ASLO will check
> Browse's user agent string) will somehow recognize what activities work
> fine for them and what don't.
>
>    

This would be a great thing to have in place.
> [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy
>
>