Do you have the details re the broken activities? regards.
-walter On Wed, Apr 19, 2017 at 1:30 AM, Tony Anderson <tony_ander...@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 > a...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/aslo > -- Walter Bender Sugar Labs http://www.sugarlabs.org <http://www.sugarlabs.org>
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel