<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">At the cited meeting, I was prepared to
update the status of activities on ASLO and github. However, there
was <br>
no interest. <br>
<br>
A quick summary: There are 514 activities divided into three
groups: <br>
83 which have the current version from github installed on
aslo (<a class="moz-txt-link-freetext" href="http://activities.sugarlabs.org/activities/">http://activities.sugarlabs.org/activities/</a>)<br>
104 which are in github but not installed on aslo (and hence
not available to our users)<br>
324 which are installed in ASLO but not in github<br>
<br>
The primary problem with the 104 activities is the failure to
update the version number. This appears to result from an <br>
erroneous instruction that the update to the version should be
made by the mythical maintainer. This is contrary to Sugar
practice <br>
over the past 10+ years. The practice has been for the
developer/maintainer to update the version number when releasing a
change. <br>
As an example, the version number of Turtle Blocks (Art) is 216.
Only the person making the changes knows when the implementation
is <br>
complete and ready for release and so must commit the version
number change.<br>
<br>
It would be a simple matter to update the version numbers (I have
for the school server aslolite). As a result, our users on Ubuntu
may have access to 187 activities.<br>
<br>
It is amazing when we are worried about code coverage to find
several activities in github that do not have setup.py. Certainly,
whoever is posting changes to github can take the time to run
python setup.py.<br>
<br>
There were three activities where setup.py failed due to errors in
po. In two cases, the file contained duplicate entries - this was
trivial to fix. In another, setup.py crashed in genpot!<br>
<br>
Along with wanting Music Blocks in Sugarizer, it would be nice to
find it in ASLO. Without a specific release, the user is left to
find out whether the current code is in a stable state. This, of
course, is the reason for version numbers. It separates tested
releases from ongoing development versions. <br>
<br>
A essential element of the github process is to mark versions as
released so that real maintainers can reproduce the environment in
a bug report. <br>
<br>
Reports from users would be more likely if they were given serious
attention instead of the normal handwaving. My report on the
version problem with HelloWorld - chosen as a simple example of
the problem - was to remove it from public view!<br>
<br>
What we have needed for a long time is a system like the one Adam
Holt created at OLPC - a <a class="moz-txt-link-abbreviated" href="mailto:help@sugarlabs.org">help@sugarlabs.org</a> monitored by a
volunteer team that would respond and try to find a solution to
the problems (support gang).<br>
<br>
Tony<br>
<br>
<br>
<br>
On Thursday, 17 May, 2018 05:25 AM, Walter Bender wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADf7C8s3+SpnTFc4YLnUbK=kLSNBf6A2+Ny89jRUXzO+XVNEsQ@mail.gmail.com">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, May 16, 2018 at 5:09 PM James Cameron
<<a href="mailto:quozl@laptop.org" target="_blank"
moz-do-not-send="true">quozl@laptop.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On Wed, May 16, 2018 at
10:27:59PM +0200, Lionel Laské wrote:<br>
> Hi all,<br>
> <br>
> I've read on a recent sugar-meeting questions regarding
Sugarizer<br>
> packaging.<br>
> Because I've just released version 1.0,<br>
<br>
Thanks for the reminder; I've rebased the Sugar Labs clone
of your<br>
Sugarizer repository.<br>
<br>
> I think it's the right time to build a Sugarizer FAQ.
I'm answering<br>
> below on questions asked during this meeting but I will
be please to<br>
> add to this future FAQ all questions you're interested
to ask. Don't<br>
> be shy :-)<br>
<br>
My remaining question at the end of my mail.<br>
</blockquote>
<div><br>
</div>
<div>I'll post my questions at the end as well. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
> Who is responsible of the packaging of Sugarizer ? Who
choose<br>
> activities distributed inside Sugarizer ?<br>
> <br>
> I'm choosing all activities integrated into the
Sugarizer package.<br>
> <br>
> It's an editorial choice. It's also a way to simplify
use of<br>
> Sugarizer by non technical guys.<br>
> <br>
> Finally it's a way to ensure a good quality: I spent
lot of time<br>
> before each release to test each activity on each
supported platform<br>
> (Chrome, Firefox, Safari, EDGE, Android, iOS, ChromeOS,
Windows 10).<br>
<br>
Thanks. This is the same strategy I use for OLPC OS on
Fedora and<br>
Ubuntu, and for Sugar Live Build. The results are;<br>
<br>
- completeness,<br>
<br>
- complementary activities, due to careful selection,<br>
<br>
- reduced software defects distributed, due to full testing.<br>
<br>
I've done this because the individual activity model only
worked<br>
when there was a feedback path from the end-user to an
activity<br>
maintainer. Without activity maintainers, I've had to take
most of<br>
that role myself. Without feedback, fatal bugs have gone
undetected<br>
for months to years at a time.<br>
</blockquote>
<div><br>
</div>
<div>As a sometimes activity maintainer, my biggest issue is
that I get zero feedback from the deployments about bugs or
anything else for that matter. This is true for both Sugar
and Sugarizer. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
> BTW all deployment is free to change (add/remove)
activities<br>
> packaged in Sugarizer - see below.<br>
> <br>
> <br>
> <br>
> Is it possible to change activities package into
Sugarizer ?<br>
> <br>
> Because each activities has it's own directory in
Sugarizer, It's<br>
> easy to change the packaging. See here:<br>
> <a href="https://github.com/llaske/Sugarizer#"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/llaske/Sugarizer#</a>
activities for more.<br>
> <br>
> On Sugarizer application (Android, iOS, Windows 10)
it's not<br>
> possible to install/remove dynamically a new activity.
It's today a<br>
> technical limitation: all downloads must be sandboxed.<br>
<br>
Thanks for confirming that. One of my customers was under
the<br>
impression that activities could be downloaded and installed
within<br>
Sugarizer, but I was sure it wasn't a supported deployment
model.<br>
<br>
Another customer liked the idea of a child _not_ being
allowed to<br>
download unauthorised activities, akin to not allowing
wireless on<br>
Sugar, or providing boundary router blocking at a school.
Some of<br>
the schools I've worked with have such filtering that they
may as well<br>
not be considered as connected to the internet. ;-)<br>
<br>
> So to change packaging for Sugarizer application, you
will need to<br>
> rebuild the Cordova package. See here:<br>
> <a
href="https://github.com/llaske/Sugarizer#build-application-for-android-ios-or-windows-10"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/llaske/Sugarizer#build-application-for-android-ios-or-windows-10</a><br>
> for more.<br>
> <br>
> Note also than Sugarizer Server Dashboard allow each
deployment to<br>
> choose favorite activities (on the home view by
default). Just click<br>
> on Activities button and change favorite state in the
dashboard. You<br>
> could also change activities order.<br>
> <br>
> <br>
> <br>
> Is the Sugarizer library close to matching the Sugar
activities library ?<br>
> <br>
> Sugar activities library is very huge: I've counted
more than 1000<br>
> activities.<br>
<br>
But as we have seen from Tony, very few of them work; now a
two-digit<br>
number.<br>
<br>
> It's difficult to imagine to port all activities:
activities should<br>
> be rewritten (no direct translation from Python/Gtk to<br>
> JavaScript/HTML). Plus, not all are really used on the
field.<br>
> <br>
> So my porting strategy was:<br>
> <br>
> ● G1G1 activities: Record, Calculate, Memory, Chat,
Maze, Paint,<br>
> Speak, Moon, Clock, Physics, Abacus, Turtle,
Scratch, Etoys,<br>
> Pippy (Jappy), …<br>
> ● Most used activities in deployment: Fototoon,
Labyrinth, Tuxmath<br>
> (Tank Operation), …<br>
> ● Activity asked by OLPC France deployments: Video
Viewer (Khan<br>
> Academy, Canope), Shared Notes, QRCode, …<br>
> ● Other activities proposed by contributors: Gears,
ColorMyWorld,<br>
> Game Of Life, …<br>
> <br>
> I'm hearing from you to adapt priority and to port some
specific<br>
> activities that could be useful on the field.<br>
<br>
Thanks for following up on the meeting questions. I've two
more.<br>
<br>
1. for Sugar activities that are written in
JavaScript/HTML, yours is<br>
a hostile fork; unilateral, without consultation, and
without code<br>
changes shared between the forks after the split. We could
be adding<br>
Sugarizer's activities to Sugar, and this would benefit both
Sugar and<br>
Sugarizer; more eyes on code, more users of the activities.
What are<br>
your plans on this aspect?<br>
<br>
2. schools who have chosen to use Linux have no download
option for<br>
Sugarizer; why is that? Are you expecting those schools to
use Sugar<br>
instead?<br>
<br>
> <br>
> Best regards.<br>
> <br>
> Lionel.<br>
<br>
-- <br>
James Cameron<br>
<a href="http://quozl.netrek.org/" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://quozl.netrek.org/</a><br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org"
target="_blank" moz-do-not-send="true">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</blockquote>
</div>
<br clear="all">
<div>1. How do I keep, for example, Turtle Blocks current within
Sugarizer. Since there are local patches being made, it is not
easy for me as a developer to keep things current. I've
reached out on occasion to Michael for help, but it seems
really awkward from outside looking in to keep the Sugarizer
version up to date. Perhaps git-subtree [1] could be
considered?</div>
<div><br>
</div>
<div>2. Do you have a plan for reconciling the licensing issue
[2]? The issue is marked as Wont Fix, but I don't think that
is adequate. In addition, there has been a lot of unilateral
re-licensing of GPL and AGPL content to Apache. This is not
OK. We could ask the SFC for their advice as to how to
proceed.</div>
<div><br>
</div>
<div>3. While I agree with many of the criteria that you and
James are using for your packaging decisions, I would think it
would be in all of our interests to discuss these decisions
more broadly. There are a number of community members with a
great deal of experience in both pedagogy and deployments whom
we could learn from. Perhaps an occasional open meeting to
discuss this?</div>
<div><br>
</div>
<div>3A. What is the process by which I can lobby to get Music
Blocks included?</div>
<div><br>
</div>
<div>[1] <a
href="http://alistra.ghost.io/2014/11/30/git-subtree-a-better-alternative-to-git-submodule/"
moz-do-not-send="true">http://alistra.ghost.io/2014/11/30/git-subtree-a-better-alternative-to-git-submodule/</a></div>
<div>[2] <a href="https://github.com/llaske/sugarizer/issues/48"
moz-do-not-send="true">https://github.com/llaske/sugarizer/issues/48</a></div>
<div><br>
</div>
<div>regards.</div>
<div><br>
</div>
<div>-walter</div>
-- <br>
<div dir="ltr"
class="gmail-m_-8814551240767155751gmail_signature">
<div dir="ltr">
<div><font><font>Walter Bender</font></font><br>
<font><font>Sugar Labs</font></font></div>
<div><font><a href="http://www.sugarlabs.org"
target="_blank" moz-do-not-send="true"><font>http://www.sugarlabs.org</font></a></font><br>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>