[Sugar-devel] FAQ on Sugarizer

[Walter Bender]

On Wed, May 16, 2018 at 5:09 PM James Cameron <quozl at laptop.org> wrote:

> On Wed, May 16, 2018 at 10:27:59PM +0200, Lionel Laské wrote:
> > Hi all,
> >
> > I've read on a recent sugar-meeting questions regarding Sugarizer
> > packaging.
> > Because I've just released version 1.0,
>
> Thanks for the reminder; I've rebased the Sugar Labs clone of your
> Sugarizer repository.
>
> > I think it's the right time to build a Sugarizer FAQ.  I'm answering
> > below on questions asked during this meeting but I will be please to
> > add to this future FAQ all questions you're interested to ask. Don't
> > be shy :-)
>
> My remaining question at the end of my mail.
>

I'll post my questions at the end as well.

>
> > Who is responsible of the packaging of Sugarizer ? Who choose
> > activities distributed inside Sugarizer ?
> >
> > I'm choosing all activities integrated into the Sugarizer package.
> >
> > It's an editorial choice. It's also a way to simplify use of
> > Sugarizer by non technical guys.
> >
> > Finally it's a way to ensure a good quality: I spent lot of time
> > before each release to test each activity on each supported platform
> > (Chrome, Firefox, Safari, EDGE, Android, iOS, ChromeOS, Windows 10).
>
> Thanks.  This is the same strategy I use for OLPC OS on Fedora and
> Ubuntu, and for Sugar Live Build.  The results are;
>
> - completeness,
>
> - complementary activities, due to careful selection,
>
> - reduced software defects distributed, due to full testing.
>
> I've done this because the individual activity model only worked
> when there was a feedback path from the end-user to an activity
> maintainer.  Without activity maintainers, I've had to take most of
> that role myself.  Without feedback, fatal bugs have gone undetected
> for months to years at a time.
>

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.

>
> > BTW all deployment is free to change (add/remove) activities
> > packaged in Sugarizer - see below.
> >
> >
> >
> > Is it possible to change activities package into Sugarizer ?
> >
> > Because each activities has it's own directory in Sugarizer, It's
> > easy to change the packaging. See here:
> > https://github.com/llaske/Sugarizer# activities for more.
> >
> > On Sugarizer application (Android, iOS, Windows 10) it's not
> > possible to install/remove dynamically a new activity. It's today a
> > technical limitation: all downloads must be sandboxed.
>
> Thanks for confirming that.  One of my customers was under the
> impression that activities could be downloaded and installed within
> Sugarizer, but I was sure it wasn't a supported deployment model.
>
> Another customer liked the idea of a child _not_ being allowed to
> download unauthorised activities, akin to not allowing wireless on
> Sugar, or providing boundary router blocking at a school.  Some of
> the schools I've worked with have such filtering that they may as well
> not be considered as connected to the internet.  ;-)
>
> > So to change packaging for Sugarizer application, you will need to
> > rebuild the Cordova package. See here:
> >
> https://github.com/llaske/Sugarizer#build-application-for-android-ios-or-windows-10
> > for more.
> >
> > Note also than Sugarizer Server Dashboard allow each deployment to
> > choose favorite activities (on the home view by default). Just click
> > on Activities button and change favorite state in the dashboard. You
> > could also change activities order.
> >
> >
> >
> > Is the Sugarizer library close to matching the Sugar activities library ?
> >
> > Sugar activities library is very huge: I've counted more than 1000
> > activities.
>
> But as we have seen from Tony, very few of them work; now a two-digit
> number.
>
> > It's difficult to imagine to port all activities: activities should
> > be rewritten (no direct translation from Python/Gtk to
> > JavaScript/HTML). Plus, not all are really used on the field.
> >
> > So my porting strategy was:
> >
> >   ● G1G1 activities: Record, Calculate, Memory, Chat, Maze, Paint,
> >     Speak, Moon, Clock, Physics, Abacus,  Turtle, Scratch, Etoys,
> >     Pippy (Jappy), …
> >   ● Most used activities in deployment: Fototoon, Labyrinth, Tuxmath
> >     (Tank Operation), …
> >   ● Activity asked by OLPC France deployments: Video Viewer (Khan
> >     Academy, Canope), Shared Notes, QRCode, …
> >   ● Other activities proposed by contributors: Gears, ColorMyWorld,
> >     Game Of Life, …
> >
> > I'm hearing from you to adapt priority and to port some specific
> > activities that could be useful on the field.
>
> Thanks for following up on the meeting questions.  I've two more.
>
> 1.  for Sugar activities that are written in JavaScript/HTML, yours is
> a hostile fork; unilateral, without consultation, and without code
> changes shared between the forks after the split.  We could be adding
> Sugarizer's activities to Sugar, and this would benefit both Sugar and
> Sugarizer; more eyes on code, more users of the activities.  What are
> your plans on this aspect?
>
> 2.  schools who have chosen to use Linux have no download option for
> Sugarizer; why is that?  Are you expecting those schools to use Sugar
> instead?
>
> >
> > Best regards.
> >
> >        Lionel.
>
> --
> James Cameron
> http://quozl.netrek.org/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

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?

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.

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?

3A. What is the process by which I can lobby to get Music Blocks included?

[1]
http://alistra.ghost.io/2014/11/30/git-subtree-a-better-alternative-to-git-submodule/
[2] https://github.com/llaske/sugarizer/issues/48

regards.

-walter
-- 
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/sugar-devel/attachments/20180516/db71d686/attachment-0001.html>