[Sugar-devel] [ASLO] Testing of Activities
tony_anderson at usa.net
Wed Apr 19 19:18:35 EDT 2017
I posted issues for each indicating the results of the tests.
On 04/19/2017 08:50 PM, Walter Bender wrote:
> Do you have the details re the broken activities?
> 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.
> ASLO mailing list
> ASLO at lists.sugarlabs.org <mailto:ASLO at lists.sugarlabs.org>
> Walter Bender
> Sugar Labs
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel