[Sugar-devel] ASLO QA process

[Aleksey Lim]

On Thu, Apr 29, 2010 at 09:54:12AM -0300, Daniel Drake wrote:
> On 29 April 2010 09:46, Bernie Innocenti <bernie at codewiz.org> wrote:
> > I liked your proposal of creating per-deployment collections to manage a
> > set of activities that has been tested and approved. I think this is one
> > of the things Uruguay wanted.
> >
> > If we decided to go this path, what would be missing? Does our update
> > API support collections? Can anyone create a collection easily?
> 
> More requirements:
> 
> 1. Support for content bundles

I even added initial .xol support but removed it since no one used this
functionality and this feature was making ASLO patch more messy.
In my mind just adding .xol files support in addition to .xo won't be
useful, just place .xols to wiki will be more useful. Having .xol on
ASLO has bunch of issues:

* different UI for .xols
* different internals like removing SugarPlatform or versions of .xol
  that are not versions of activities
* different UI for .xol uploader
* complicate ASLO patch, there is no one who is PHP experienced and 
  can contribute to ASLO
* it could be a bit messy to have Activities Library(ASLO) and store
  .xols there

Having all these, and that there is real need in a method to share users
journal object (like TA projects), I decided instead of trying to
implement this functionality on ASLO, (continue)make Library activity, thus
pure python way. 

Everything I posted about Activities_Library will be implemented firstly
for regular journal objects (including .xol).

> 2. Locking to specific versions (maybe already possible with
> collections -- not sure) rather than a collection always including the
> latest

Will be easy to implement

> 3. Reproducibility in low-connectivity deployments, or even for cases
> such as paraguay where connectivity is good but going to ASLO will
> really be sloooow and it's much more desirable to set up some simple
> infrastructure to run it within the school. i.e. that simple
> infrastructure needs to be developed and good documentation needs to
> be written.
> 
> (easiest approach for #3: support OLPC activity microformat. clean,
> simple format, well documented, designed for low connectivity
> situations, simple infrastructure is already developed and has been
> replicated around the world.)

As I can understand microformat, it will be just xml/http page with info
about activities i.e. similar to update-aslo.php script. Last time I
thought about it I didn't get feedback and decided that it is not
important (especially after adding ASLO Updater to sugar).

-- 
Aleksey