[Sugar-devel] ASLO QA process

[Bernie Innocenti]

El Sat, 24-04-2010 a las 07:19 +0000, Aleksey Lim escribió:
> In my mind activities on ASLO are not something like packages in regular
> GNU/Linux distribution. ASLO is not one centralized product, as already
> was mentioned several times it is (or should) palace to share your work
> (maybe in trash) with others thus we (will)have bunch of outdated/
> forgotten projects. And it is ok for sugar (but not for GNU/Linux
> distributions).

I also intended ASLO this way, until I realized that builds are being
composed by picking the latest versions of activities from ASLO
directly. Same goes for the update control panel.

Because of this, users expect the things they find on ASLO to actually
work and get pissed off if a new version of an activity breaks horribly.

Distributors (like Paraguay Educa and OLPC) need to introduce a QA layer
somewhere between the activity authors and the users. Whether we thought
it this way or not, bundles on ASLO are equivalent to distro packages.


> And also most of activities come from individuals i.e. it's their
> masterpieces. So, lets talking about "forking" not about "taking over".

Ok, but we need to make sure that there's a way for one of these forks
to become an automatic update for an abandoned activity.

Moreover, there's the question of finding good names for activities.
If the maintainer of Browse disappears, I wouldn't want to tell users:
"now you should download BernieBrowse instead of Browse".


> In my mind instead of increasing level of bureaucracy in sugar, for now,
> we could ping authors/nd publish forks on ASLO (with new bundle_id) and
> start implementing new Activities Library with taking into account all
> sugar specific (ASLO in case of AMO is not such, since Mozilla controls
> AMO addons and it is mostly centralized repo w/ QA etc).

I agree with you that we should keep bureaucracy to a minimum.

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?


> I'm working on Activities Library (on early stage). It will look
> like:
> 
> * server in the person of buddy in F1 view with shared instance of
>   Library activity
> * any user can join this instance to see what activities are on
>   the server
> * can just click to launch
> * can share new activity or fork of existed
> * any user can be such server, he just need to follow regular sugar
>   practice, create new instance of Library and share it
> 
> Any ideas are welcome
> http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library

Fantastic project!

Will it support multiple libraries, for the same of decentralizing
things?

I can imagine that many deployments would want a hierarchical thing to
save bandwidth and delegate decisions to school principals: the
schoolserver would be the first place where children search for
activities, then would come the deployment server and lastly ASLO.

I think dsd did something like this for the old updater.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/