Re: [Sugar-devel] Port to TelepathyGLib
Hi, On Thu, May 17, 2018 at 3:11 AM, James Cameronwrote: > As you may have seen in my post in the last hour, forks of software > dilute maintainership, and everyone is worse off. > As part of porting to Python 3, we need to port to TelepathyGLib as > well. This is because there is no maintained static binding of > Telepathy for Python 3. > If we were to bundle Telepathy inside Sugar, we would most likely lose > automatic maintenance of Telepathy. Downstream distribution packagers > know about this risk, and often give upstream projects a nudge about > it. An example is the Rsvg static binding that, while it was quite > trivial, became a hot topic and eventually caused our GTK+ 2 toolkit > to be dropped from Debian and Ubuntu, despite other GTK+ 2 > applications remaining. Thanks for the detailed explanation. I agree, we should port. > We may face other ports as well. We're yet to uncover them, and may > only uncover them by trying to run the code. I'm hoping we don't have > to port from static binding for D-Bus, but I won't know until we test > the code. Yes, I am not yet sure about D-Bus > Don't worry about the 72 results of search; > 1. many of those activities don't work now, so there would be no > significant gain from porting them, > 2. some activities are not in https://github.com/sugarlabs/ > 3. best to concentrate on the "Fructose" set of demonstration > activities, Sure, I will keep this in mind, Thank you > Perhaps the patterns of change can be expressed as a sed(1) script and > added to your sugar-docs Port to Python 3 checklist? This will help > people like me who have activities to maintain. Sure, I will make one soon. Thanks Rahul Bothra (Pro-Panda) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FAQ on Sugarizer
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] Port to TelepathyGLib
Thanks for working on this. As you may have seen in my post in the last hour, forks of software dilute maintainership, and everyone is worse off. As part of porting to Python 3, we need to port to TelepathyGLib as well. This is because there is no maintained static binding of Telepathy for Python 3. If we were to bundle Telepathy inside Sugar, we would most likely lose automatic maintenance of Telepathy. Downstream distribution packagers know about this risk, and often give upstream projects a nudge about it. An example is the Rsvg static binding that, while it was quite trivial, became a hot topic and eventually caused our GTK+ 2 toolkit to be dropped from Debian and Ubuntu, despite other GTK+ 2 applications remaining. We may face other ports as well. We're yet to uncover them, and may only uncover them by trying to run the code. I'm hoping we don't have to port from static binding for D-Bus, but I won't know until we test the code. Don't worry about the 72 results of search; 1. many of those activities don't work now, so there would be no significant gain from porting them, 2. some activities are not in https://github.com/sugarlabs/ 3. best to concentrate on the "Fructose" set of demonstration activities, Thanks for demonstrating the port complexity in the toolkit https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/389/commits/a6f2cdaca58bc737d825365afd7bd3d7f12c530c Perhaps the patterns of change can be expressed as a sed(1) script and added to your sugar-docs Port to Python 3 checklist? This will help people like me who have activities to maintain. On Thu, May 17, 2018 at 12:17:19AM +0530, Rahul Bothra wrote: > Hi, > > I started understanding how Telepathy and DBus work, and porting our code to > use their PyGI bindings instead of static bindings, and it looks like a big > task. > Also, GitHub search gives 72 results [1]https://github.com/search?p=5= > org%3Asugarlabs+%22from+telepathy%22=Code=%E2%9C%93 for instances of > telepathy > > Instead, Should we pack the static binding port of Telepathy inside > Sugar-Toolkit. The only change that will then have to be made will be: > "from telepathy.foo import bar" will have to be changed to "from > sugar3.telepathy.foo import bar" > > Please suggest if there can be any disadvantages in following this approach ? > (Sorry, if it is obvious) > > Regards > Rahul Bothra (Pro-Panda) > > On Wed, May 16, 2018 at 3:56 AM, James Cameron <[2]qu...@laptop.org> wrote: > > On Tue, May 15, 2018 at 11:02:49PM +0530, Rahul Bothra wrote: > > - Rahul will also contact upstream(s) of Telepathy to ask their > > plans of a Python 3.x Telepathy version > > Telepathy upstream suggested using PyGObject API, available for both > Python 2 and Python 3. > > [3]https://lazka.github.io/pgi-docs/#TelepathyGLib-0.12 > > On Ubuntu 18.04 install package gir1.2-telepathyglib-0.12 and then > this test passes; > > $ python2 > >>> from gi.repository import TelepathyGLib > > $ python3 > >>> from gi.repository import TelepathyGLib > > For the moment, development can happen with your static binding port > of Telepathy, but we should not plan to rely on it, because > downstreams already have a Python 3 Telepathy in the form of > TelepathyGLib. > > So we must port. > > [4]https://github.com/orgs/sugarlabs/projects updated with new "Port to > TelepathyGLib" > [5]https://github.com/orgs/sugarlabs/projects/4 > > > Change from > > from telepathy.foo import bar > > to > > import gi > gi.require_version('TelepathyGLib', '0.12') > from gi.repository import TelepathyGLib > > Prerequisite for Port to Python 3. > > > -- > James Cameron > [6]http://quozl.netrek.org/ > ___ > Sugar-devel mailing list > [7]Sugar-devel@lists.sugarlabs.org > [8]http://lists.sugarlabs.org/listinfo/sugar-devel > > References: > > [1] > https://github.com/search?p=5=org%3Asugarlabs+%22from+telepathy%22=Code=%E2%9C%93 > [2] mailto:qu...@laptop.org > [3] https://lazka.github.io/pgi-docs/#TelepathyGLib-0.12 > [4] https://github.com/orgs/sugarlabs/projects > [5] https://github.com/orgs/sugarlabs/projects/4 > [6] http://quozl.netrek.org/ > [7] mailto:Sugar-devel@lists.sugarlabs.org > [8] http://lists.sugarlabs.org/listinfo/sugar-devel -- James Cameron http://quozl.netrek.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FAQ on Sugarizer
On Wed, May 16, 2018 at 5:09 PM James Cameronwrote: > 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
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
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
Re: [Sugar-devel] Port to TelepathyGLib
Hi, I started understanding how Telepathy and DBus work, and porting our code to use their PyGI bindings instead of static bindings, and it looks like a big task. Also, GitHub search gives 72 results https://github.com/search?p=5=org%3Asugarlabs+%22from+telepathy%22=Code=%E2%9C%93 for instances of telepathy Instead, Should we pack the static binding port of Telepathy inside Sugar-Toolkit. The only change that will then have to be made will be: "from telepathy.foo import bar" will have to be changed to "from sugar3.telepathy.foo import bar" Please suggest if there can be any disadvantages in following this approach ? (Sorry, if it is obvious) Regards Rahul Bothra (Pro-Panda) On Wed, May 16, 2018 at 3:56 AM, James Cameronwrote: > On Tue, May 15, 2018 at 11:02:49PM +0530, Rahul Bothra wrote: > > - Rahul will also contact upstream(s) of Telepathy to ask their > > plans of a Python 3.x Telepathy version > > Telepathy upstream suggested using PyGObject API, available for both > Python 2 and Python 3. > > https://lazka.github.io/pgi-docs/#TelepathyGLib-0.12 > > On Ubuntu 18.04 install package gir1.2-telepathyglib-0.12 and then > this test passes; > > $ python2 > >>> from gi.repository import TelepathyGLib > > $ python3 > >>> from gi.repository import TelepathyGLib > > For the moment, development can happen with your static binding port > of Telepathy, but we should not plan to rely on it, because > downstreams already have a Python 3 Telepathy in the form of > TelepathyGLib. > > So we must port. > > https://github.com/orgs/sugarlabs/projects updated with new "Port to > TelepathyGLib" > https://github.com/orgs/sugarlabs/projects/4 > > > Change from > > from telepathy.foo import bar > > to > > import gi > gi.require_version('TelepathyGLib', '0.12') > from gi.repository import TelepathyGLib > > Prerequisite for Port to Python 3. > > > -- > James Cameron > http://quozl.netrek.org/ > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel