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. [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy -- Aleksey _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
