[Sugar-devel] Testing of Activities

[Tony Anderson]

I spent the last two plus days testing the 137 activities with 
repositories in github/sugarlabs.

Of these, 103 work on Ubuntu 16.04 sucrose. This leaves 34 which do not 
work.

The biggest problem is version control. Most of these activities were 
placed in github during GCI early in 2016. The two main contributers 
apparently were unaware of the activity version number in activity.info. 
As a result, even after upgrading to GTK3 (sugar3), the version number 
was unchanged from the original taken from ASLO. This caused a lot of 
lost time as a test on the version in ASLO failed only to find that the 
version in github worked.

In many cases the activity version shown to users of ASLO is not the 
most recent version (and, indeed, is a non-working version although 
there is a working version available). The most recent version as the 
result of some quirk in procedure or software is available by the 'view 
older versions' link. At the top of that screen is the warning: Be 
careful with old versions.

Try to imagine the reaction of a Sugar user who downloads an activity 
from ASLO which fails to start. I can't think of anything more likely to 
turn off a learner.

It was possible to get several working by obtaining a missing component 
or in case of the MaMaMedia activities, to remove reference to abiword 
(losing the integral lessons). In other cases the GCI contributors 
failed to complete the upgrade to GTK3 which has the property that it is 
all or nothing. So in several cases, the activity fails because of an 
indirect or overlooked reference to gobject. One concern is activities 
based on a screen-size of 1200x900. One game activity is unplayable 
because essential controls are off the screen (1024x768).

As a community we need to come up with standards and procedures for 
creating and maintaining activities in github.

     Presumably, this is managed by an Activity Team. While there are 
many registered members and owners, many of them are not active at the 
moment. The website description of the Activity Team is obsolete (dates 
from 2014

Currently someone who wants to contribute an activity registers with the 
developer hub on ASLO. This request is answered by email similar to the 
procedure for joining an mail list. How is that to be handled now.

It appears that most of the changes made by GCI contributors were done 
by direct git commits. However, more generally, work on an activity 
would be done on a clone to later be merged through the PR process. As 
now, actual release of an activity to ASLO is done by someone other than 
the developer. So one could imagine a process where a responsible member 
of the Activity Team would generate a bundle with setup.py and install 
the bundle as the most recent version on ASLO with an updated version 
number.

Currently, ASLO displays information about the activity that is not 
available in the bundle itself such as the developer, summary, 
description, 'works with', release notes, home page, and repository 
link. Perhaps the standard should be to include this information in the 
bundles activity.info so the ASLO page could be generated by examination 
of the bundle. The 'works with' needs to be expanded to show which 
platforms are supported. In addition, it should show specific 
restrictions. A classic is the level activity which requires an XO with 
an accelerometer. Any other Sugar user should pass. Others require 
special hardware such as a midi connection, a makeymakey or gogo board, 
or Butia components.

Localization also needs some attention. The setup.py enables a developer 
to generate a master Pot file while building a bundle for release to 
ASLO. That is probably the limit of the developer's responsibility. 
However, existing activities over time have developed localization for 
many languages. Changes to the messages will need new translations. 
Perhaps the developer can use diff to find differences in the Pot and to 
eliminate un-needed changes and test that new messages are passed 
through. This could enable prompt release of a new version without 
waiting for the localization team to provide translations for dozens of 
languages.

Tony