[ASLO] Testing of Activities

[Tony Anderson]

I posted issues for each indicating the results of the tests.

Tony

On 04/19/2017 08:50 PM, Walter Bender wrote:
> Do you have the details re the broken activities?
>
> regards.
>
> -walter
>
> On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson <tony_anderson at usa.net 
> <mailto:tony_anderson at usa.net>> wrote:
>
>     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 <http://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 <http://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
>     _______________________________________________
>     ASLO mailing list
>     ASLO at lists.sugarlabs.org <mailto:ASLO at lists.sugarlabs.org>
>     http://lists.sugarlabs.org/listinfo/aslo
>     <http://lists.sugarlabs.org/listinfo/aslo>
>
>
>
>
> -- 
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170420/4a5f738b/attachment.html>