Re: [Sugar-devel] FAQ on Sugarizer

[Dave Crossland]

On 17 May 2018 at 13:44, Lionel Laské  wrote:

>
>
> 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.
>>
>>
> I'm not familiar enough with licenses compatibilities to have a clear
> opinion. I'm agree to hear advices on it.
>

Great! With the 'wontfix' label I assumed that your position was settled,
but since you would like to discuss, then I posted some further
clarifications of my position on the Github issue (
https://github.com/llaske/sugarizer/issues/48) :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] FAQ on Sugarizer

[bzg]

Hi Walter and Lionel,

Lionel Laské  writes:

> 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.

I think it's fine to ask SFC advice, but we should list issues first.

Porting a software to another language/framework is not reusing code,
so Lionel's answer seems fine to me in issues #48[1].

But if some content has been published under GPLv2(+) or GPLv3(+)
then relicensed under Apache 2.0, that's probably a mistake and we
certainly should fix it.

I'm willing to help in this area.

[1]  https://github.com/llaske/sugarizer/issues/48

-- 
 Bastien
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] FAQ on Sugarizer

[bzg]

Hi Lionel and all,

I just subscribed to this list again, 'feels good!

Lionel Laské  writes:

> I'm not familiar with Linux packaging but if a guy would like to
> package Sugarizer as a Linux package, I could help.

I may be worth exploring https://www.flatpak.org for this.

2 cts,

-- 
 Bastien
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] FAQ on Sugarizer

[Lionel Laské]

2018-05-16 23:25 GMT+02:00 Walter Bender :

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.
>

Yes, it's true.


> 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?
>
>
As I said to James, when the maintainer for a Sugarizer activity still
maintain its repo (a minority of Sugarizer activities), I'm trying to send
regularly PR to ensure that Sugarizer compatibility is still there. I
didn't know subtree feature. Sounds good. Not sure to fully understand how
it works. BTW I'm not opposed to test it.


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.
>
>
I'm not familiar enough with licenses compatibilities to have a clear
opinion. I'm agree to hear advices on it.



> 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?
>
>
Sure. Why not.



> 3A. What is the process by which I can lobby to get Music Blocks included?
>
>
I don't have enough music knowledge but Music Blocks look like a good
replacement for the G1G1 TamTam suite. It will nice to integrate it in
Sugarizer.
My concerns about it is:
- It was not conceived with Sugar-web in mind so it should be adapted to
handle datastore and propose the minimal Sugar UI need: a stop button. BTW
I guess it should be the same work done in TurtleJS ?
- It's not tested on Safari and EDGE which it's a platform need for
Sugarizer. There is some UI issue on EDGE for example.
- Activity size is huge (68Mb), it's an important thing to consider when
deploying on stores. Android for example limit applications size to 100Mb
and Sugarizer size is already 60Mb (without Abecedarium sounds). May be
Music Blocks size could be reduced ?

Best regards.

  Lionel.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] FAQ on Sugarizer

[Lionel Laské]

2018-05-16 23:09 GMT+02:00 James Cameron :

>
> Thanks for the reminder; I've rebased the Sugar Labs clone of your
> Sugarizer repository.
>

Nice. Thanks.

>
> > 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.
>
>
> 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.
>
>
Good to hear that. Very similar to my work, for sure.



>
> 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.  ;-)
>
>
It's very similar on OLPC France deployments, both for Sugar and for
Sugarizer.
Activities are chosen by teachers and on our Sugar deployments, the
internet access don't allow to download new activities.


>
> 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?
>
>
Not sure to understand what you call an "hostile fork".
I've copied repo from activities included into Sugarizer but always with
author authorization.
Most of the times (80% of activities included in Sugarizer) the maintainer
decide to not maintain its repo outside Sugarizer after the copy. In that
case, Sugarizer repo become the place where the activity is maintain.
When the maintainer continue to maintain the activity in it's own repo -
for example TurtleJS - I'm trying to send PR regularly to integrate my
change.



> 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?
>
>
Sugarizer could be used from any web browser so it's easy to install on a
School Server and run it from any Linux machine.
It's also possible to install it locally from the repo and run it using
browser and a "file://" call.
I'm not familiar with Linux packaging but if a guy would like to package
Sugarizer as a Linux package, I could help.

Thanks for your feedback.

Lionel.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] FAQ on Sugarizer

[Tony Anderson]

At the cited meeting, I was prepared to update the status of activities 
on ASLO and github. However, there was

no interest.

A quick summary: There are 514 activities divided into three groups:
    83  which have the current version from github installed on aslo 
(http://activities.sugarlabs.org/activities/)
   104 which are in github but not installed on aslo (and hence not 
available to our users)

   324 which are installed in ASLO but not in github

The primary problem with the 104 activities is the failure to update the 
version number. This appears to result from an
erroneous instruction that the update to the version should be made by 
the mythical maintainer. This is contrary to Sugar practice
over the past 10+ years. The practice has been for the 
developer/maintainer to update the version number when releasing a change.
As an example, the version number of Turtle Blocks (Art) is 216. Only 
the person making the changes knows when the implementation is

complete and ready for release and so must commit the version number change.

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.


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.


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!


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.


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.


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!


What we have needed for a long time is a system like the one Adam Holt 
created at OLPC - a h...@sugarlabs.org monitored by a volunteer team 
that would respond and try to find a solution to the problems (support 
gang).


Tony



On Thursday, 17 May, 2018 05:25 AM, Walter Bender wrote:



On Wed, May 16, 2018 at 5:09 PM James Cameron > 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 

Re: [Sugar-devel] FAQ on Sugarizer

[Walter Bender]

On Wed, May 16, 2018 at 5:09 PM James Cameron  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 

Re: [Sugar-devel] FAQ on Sugarizer

[James Cameron]

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.

> 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.

> 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@lists.sugarlabs.org

[Sugar-devel] FAQ on Sugarizer

[Lionel Laské]

Hi all,

I've read on a recent sugar-meeting [1] questions regarding Sugarizer
packaging.
Because I've just released version 1.0, 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 :-)


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).

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. 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.

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.


Best regards.

   Lionel.


[1] http://meeting.sugarlabs.org/sugar-meeting/2018-05-15#i_2925856
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel