[IAEP] [ASLO] Testing of Activities

[Walter Bender]

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>
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.
> 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
> _______________________________________________
> ASLO mailing list
> ASLO at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/aslo
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
<http://www.sugarlabs.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170419/21d2885d/attachment.html>