<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-05-16 23:09 GMT+02:00 James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span>:<span class=""></span><br><span class=""></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>Thanks for the reminder; I've rebased the Sugar Labs clone of your<br>
Sugarizer repository.<br></blockquote><div><br></div><div>Nice. Thanks. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><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>
</span>My remaining question at the end of my mail.<br>
<span class=""><br>
<br>
</span>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>
<span class=""><br></span></blockquote><div><br></div><div>Good to hear that. Very similar to my work, for sure.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
<span class=""><br></span></blockquote><div><br></div><div>It's very similar on OLPC France deployments, both for Sugar and for Sugarizer.</div><div>Activities are chosen by teachers and on our Sugar deployments, the internet access don't allow to download new activities. <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>Not sure to understand what you call an "hostile fork".</div><div>I've copied repo from activities included into Sugarizer but always with author authorization.</div><div>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.<br></div><div>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.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>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.</div><div>It's also possible to install it locally from the repo and run it using browser and a "file://" call.</div><div>I'm not familiar with Linux packaging but if a guy would like to package Sugarizer as a Linux package, I could help.</div><div><br></div><div>Thanks for your feedback.</div><div><br></div><div> Lionel.</div><div><br></div><div> </div></div><br></div></div>