[Sugar-devel] ASLO QA process
Thomas C Gilliard
satellit at bendbroadband.com
Thu Apr 29 09:35:03 EDT 2010
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
> 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.
Some random thoughts:
Is there no way to detect the requesting hardware and deployment first
have ASLO filter the appropriate applications for download?
An INDEXED rpm depository to install from, or Download from would be
nice for advanced users.
I have a CD Image of 111 .xo activities for Download from:
for drag-drop "sneaker-net" installs.
Maybe a down-loadable set of these CD Images should be maintained for
different deployments and hardware.
(this would also save a lot of server usage)
> 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
>> * 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
> 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.
> I think dsd did something like this for the old updater.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel