[Sugar-devel] New ASLO features to implement

[Thomas C Gilliard]

Alexsey;

Maybe simple preliminary workaround for incompatible activity downloads:

Could a Group of working activities be created for each sugar version ie 
0.84/0.86/0.88 to be selected by user on opening ASLO?

Tom Gilliard
satellit

Bernie Innocenti wrote:
> El Tue, 15-06-2010 a las 22:31 +0000, Aleksey Lim escribió:
>   
>> Here it is my preliminary TODO (not prioritized list):
>>
>> * Support(revert) of per architecture uploads, there are bunch of
>>   activities that are binaries and having requirement to have all
>>   supported blobs could be overkill for uploaders.
>>     
>
> +1
>
>   
>> * Support per languages uploads. In some cases (GCompris, OOo4Kids)
>>   all languages in one bundle weights too much and per locale bundles makes
>>   sense. While downloading, ASLO will suggest only current locale
>>   bundle.
>>     
>
> +1 (does upstream remora already provide this?)
>
>
>   
>> * By default, ASLO just an repository of activities (not regarding their
>>   stability status) and anonymous downloading is required (for now,
>>   experimental downloads requires be logged in).
>>     
>
> +1 on allowing anonymous download of any bundle, regarding its
> stable/experimental status.
>
> -1 on showing experimental activity bundles as the default download for
> activities. Probably, even maintainers should go through a peer review
> process.
>
>
>   
>> * Current QA[1] scheme is too weak for deployment(various) needs and
>>   having previous option, more reliable scheme is required. Current plan is
>>   implementing QA profiles. Every activity could be stamped (from -n to
>>   +n) in several QA profiles. QA stamp is not part of activity itself
>>   and could be set by QA editors in any time. User can nominate activity
>>   to be stamped in several QA profiles to notify QA editors about new
>>   activity. QA editors will be notified about new version of already
>>   stamped activities via aslo at .
>>     
>
> Perhaps a simpler scheme to implement, which would be sufficient to
> fulfill our needs would be adding the ability to specify exact versions
> of bundles in collections.
>
> Then, we could simply point the updater to a page like this:
>
>  http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88
>
> The deployment people would keep the versions updated after doing their
> QA on activities.
>
>
>   
>> * Support microformat for OLPC updater. Also support collections as
>>   microformat groups. Take into account QA profiles.
>>     
>
> +1
>
>
>   
>> It could be not full list of required features. If you are interested in
>> some ASLO improvements, post an comment.
>>     
>
> Thanks Aleksey, recapitulating this list of requirements was indeed very
> helpful.
>
> I'll try to find a php developer to help out implementing these features
> ASAP. Can we make them work in the activities-devel sandbox on
> sunjammer?
>
>
>   
>> [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100616/fa4c3965/attachment.htm