[Sugar-devel] New ASLO features to implement

[Rafael Enrique Ortiz Guerrero]

On Wed, Jun 16, 2010 at 2:49 PM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Wed, Jun 16, 2010 at 08:34:10AM -0400, Bernie Innocenti wrote:
>> El Tue, 15-06-2010 a las 22:31 +0000, Aleksey Lim escribió:
>> > * 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?)
>
> At least for now, there could be only per arch/OS uploads. Don't know
> about plans but I was planing to not rebase ASLO to recent AMO (to
> minimize work).
>
>> > * 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.
>
> Keeping in mind what Rafael posted about development versions, the whole
> picture could be:
>
> * stable versions will be public automatically
> * development versions (flag should be set while uploading) will be
>  treated as current experimental uploads but w/o making them
>  public(since only next version could be stable)
> * versions stamped(somehow) by QA

Agreed :).

>> > * 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.
>
> To be honest, I also want to keep ASLO patch as minimal as possible.
> My concern about using only collections is that it is not so useful in
> regular ASLO usecase i.e. there is no way to see activities by category within
> collection. But at the end it is all about how deployments will use
> QAed activities from ASLO, if for the first time using only microformat
> groups/collections will be enough, QA stuff could be only OLPC updater
> support.
>
>> > * 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?
>
> Only shell account on sunjammer is required.
>
> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>