[Sugar-devel] ASLO QA process
alsroot at member.fsf.org
Thu Apr 29 09:58:34 EDT 2010
On Thu, Apr 29, 2010 at 08:46:06AM -0400, Bernie Innocenti wrote:
> 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.
There are no doubts that distributors need/should-have such QA layer.
The thing is that we need(imho) free style sharing repository as well.
For now, ASLO is being used in both ways:
* repository in distro meaning since there is Control Panel updater
- but it will fetch any version from ASLO w/o QA
- but having regular QA team on ASLO will make it like a regular
linux distribution w/ all related issues including loosing free
style repo meaning
* free style repo
- but such activities are marked as experimental versions that could
not be correct
- users need to be logged in to download these activities
- ASLO doesn't support forks
So, ASLO is not successful in both ways.
> > 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".
Well, with current AMO, we have to do something similar (until someone
will implement all features sugar needs in ASLO).
> > 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?
AMO doesn't support such feature by design (since there is only one
deployment for addons) but I think it could be implemented in simple
* mention particular versions while adding activities to collection
* support collections in API updater, so users will fetch updates not
from full ASLO but from particular collection
* anyone create collections and add users who can edit them, but we can
add ASLO groups for particular collection to make users management
All these steps are pretty doable.
> > 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
> 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.
Thanks, this hierarchical structure will be useful not only on pure
server side but on peers side as well, like:
* someone added bunch of cool activities to his list (w/o
* shares his Activity_Library instance
* any joined user can see|download|launch these activities
> I think dsd did something like this for the old updater.
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
More information about the Sugar-devel