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 > > _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
