[Sugar-devel] New ASLO features to implement
Rafael Enrique Ortiz Guerrero
rafael at sugarlabs.org
Wed Jun 16 18:56:43 EDT 2010
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
> 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
>> > * Current QA 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:
>> 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 microformat for OLPC updater. Also support collections as
>> > microformat groups. Take into account QA profiles.
>> > 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
>> 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
> Only shell account on sunjammer is required.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel