[Sugar-devel] New ASLO features to implement

[Aleksey Lim]

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

> > * 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