<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I posted issues for each indicating the results of the tests.<br>
<br>
Tony<br>
<br>
<div class="moz-cite-prefix">On 04/19/2017 08:50 PM, Walter Bender
wrote:<br>
</div>
<blockquote
cite="mid:CADf7C8sbAu6my5jZB-RWu8xqfzBfzC-EpUnctx4BXi4eT9Li1g@mail.gmail.com"
type="cite">
<div dir="ltr">Do you have the details re the broken activities?
<div><br>
</div>
<div>regards.</div>
<div><br>
</div>
<div>-walter</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Apr 19, 2017 at 1:30 AM, Tony
Anderson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I spent
the last two plus days testing the 137 activities with
repositories in github/sugarlabs.<br>
<br>
Of these, 103 work on Ubuntu 16.04 sucrose. This leaves 34
which do not work.<br>
<br>
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 <a moz-do-not-send="true"
href="http://activity.info" rel="noreferrer"
target="_blank">activity.info</a>. 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
As a community we need to come up with standards and
procedures for creating and maintaining activities in
github.<br>
<br>
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<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <a
moz-do-not-send="true" href="http://activity.info"
rel="noreferrer" target="_blank">activity.info</a> 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.<br>
<br>
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.<br>
<br>
Tony<br>
______________________________<wbr>_________________<br>
ASLO mailing list<br>
<a moz-do-not-send="true"
href="mailto:ASLO@lists.sugarlabs.org" target="_blank">ASLO@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/aslo"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/lis<wbr>tinfo/aslo</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div><font><font>Walter Bender</font></font><br>
<font><font>Sugar Labs</font></font></div>
<div><font><a moz-do-not-send="true"
href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>