Re: [IAEP] [Sugar-devel] [GSoC] Sugar Browser
On Sun, Mar 21, 2010 at 23:25, Lucian Branescu lucian.brane...@gmail.com wrote: Some have expressed concern about Browse and its current xulrunner dependency (http://bugs.sugarlabs.org/ticket/1850). To make matters even worse for the future, Mozilla plans to get rid of XPCOM at some point in favour of better JavaScript interfacing to C++ and a JavaScript ffi similar to ctypes. The extent up to which xulrunner will be supported by Mozilla as an embeddable engine is the most important point, IMHO. But up to now we only have rumours and speculation. Could someone add a reference to a clear statement or ask someone at Mozilla? Ubuntu's position on this is explained here, though I would prefer something clearer: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ Surf is an existing browser activity that uses webkit (pywebkitgtk). It is not yet on par feature-wise with Browse, but it could be extended. I see a few possible ways forward, that I could work on for GSoC: 1) Get Browse into shape (with a bundled xulrunner?) 2) Update Surf to be on par with Browse I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. When comparing performance, we need to compare apples to apples, which can be a lot of work. One way to move forward regarding this is to make a simpler Browse comparable in functionality to the current Surf and measure that. While gecko has superior extendability (XUL extensions), Browse isn't compatible with Firefox extensions, so anything would need to be rewritten anyway. Google gears runs unmodified on Browse. Extensions that depend on Firefox interfaces will only run on Firefox, but there are lots of extensions that only use Xulrunner interfaces. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla's Jetpack or Chrome's extensions could be implemented. Second, webkit is being used by a lot of projects and has the backing of several companies. Furthermore, it is packaged more consistently across platforms/distributions. As pointed out above, I think the maintainability issue is the most important here. While we have reasons to fear about Mozilla in this regard, we should act on more final information. Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier. Any thoughts on this? In summary, I think this is a very interesting proposal, thanks for bringing it up again. Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SoaS change of direction: heads-up on convos in other lists
On Sat, Mar 20, 2010 at 18:10, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 4:54 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Sat, Mar 20, 2010 at 12:46 PM, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 10:26 AM, Sean DALY sdaly...@gmail.com wrote: The problem with this approach is that it renders SoaS ineffective for new tryers of Sugar (i.e. the overwhelming majority of teachers and parents we are trying to reach). I don't think it will be any less ineffective than having 20 activities of which half have issues, crash or just don't run. Are people saying _only 6 activities work reliably?_ My question of which is it? was assuming there are more than 6 that run well, demo well, maintained, etc. So it meant which plan is it, 6 activities that allow downloading and installing of more, or the good ones? If there are only 6 good ones... would focus on making that list longer. Did APIs break with Sugar churn, Fedora churn? Developers upload without testing? (Rethorical! Flamefest warning! Those questions are bound to be a flamefest blaming people who don't deserve to be blamed... :-( ) I think some of or all of the above are to blame. I'm still trying to get time to test. I should do so in the next couple of weeks. Record is one of the classic ones with issues. It was broken horribly for SOAS-2 and possibly even v1 but there's been no real attempt to fix it. Part of it is also that to be in Fedora the precompiled binary crud needs to be removed and in a lot of cases Activity developers don't test it with the native libraries. Also I know Write isn't currently on the list because it doesn't work properly [1] but obviously it would be a good one to have as its a great demo of the collaboration. We also want to get away from the point where a few people are running around doing 20 hour days trying to get the release out the door. I know just prior to to the last release that Sebastian was re-spinning the release into the early hours of the morning to fix Activity bugs to get the release out the door on time for marketing the day before an exam. If people aren't going to spend the time to make sure their activity works prior to a release there's only only limited time the main people have to do the testing along with all the other release process as well as getting on with the rest of their life. So I think its better we ship with less Activities better tested that cover the core functionality. FWIW, Peter's words resonate with my feelings on this issue, but maybe this change could have been communicated differently (or maybe I'm misunderstanding its ultimate cause). How I see this issue is that the Sugar community has come to expect the SoaS maintainer(s) to test dozens of activities each release cycle and fix all the issues that may have crept in. Of course, this is an unreasonable expectation and the SoaS team has decided to reduce the scope of their work so it becomes more doable. What the SoaS team could have said instead of we'll ship half a dozen activities, is we have agreed on a criteria for activities that are to be included in a SoaS release. Such a criteria could have been something like: - the activity has been tested and works with the last Sugar release, - the community has voted this activity as sufficiently relevant to be present in SoaS, - the activity has a maintainer that will react to issues with the activity, answer questions, etc. - the activity has been packaged as a rpm and is part of Fedora. This may be more effective in tackling with the root cause, which I feel to be unreasonable expectation for the actual resources. The community would understand that the SoaS team currently doesn't have enough resources to include so many activities, and also would feel compelled to find more resources to maintain activities. Regards, Tomeu Peter [1] http://bugs.sugarlabs.org/ticket/1767 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SoaS change of direction: heads-up on convos in other lists
On Mon, Mar 22, 2010 at 9:35 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Sat, Mar 20, 2010 at 18:10, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 4:54 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Sat, Mar 20, 2010 at 12:46 PM, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 10:26 AM, Sean DALY sdaly...@gmail.com wrote: The problem with this approach is that it renders SoaS ineffective for new tryers of Sugar (i.e. the overwhelming majority of teachers and parents we are trying to reach). I don't think it will be any less ineffective than having 20 activities of which half have issues, crash or just don't run. Are people saying _only 6 activities work reliably?_ My question of which is it? was assuming there are more than 6 that run well, demo well, maintained, etc. So it meant which plan is it, 6 activities that allow downloading and installing of more, or the good ones? If there are only 6 good ones... would focus on making that list longer. Did APIs break with Sugar churn, Fedora churn? Developers upload without testing? (Rethorical! Flamefest warning! Those questions are bound to be a flamefest blaming people who don't deserve to be blamed... :-( ) I think some of or all of the above are to blame. I'm still trying to get time to test. I should do so in the next couple of weeks. Record is one of the classic ones with issues. It was broken horribly for SOAS-2 and possibly even v1 but there's been no real attempt to fix it. Part of it is also that to be in Fedora the precompiled binary crud needs to be removed and in a lot of cases Activity developers don't test it with the native libraries. Also I know Write isn't currently on the list because it doesn't work properly [1] but obviously it would be a good one to have as its a great demo of the collaboration. We also want to get away from the point where a few people are running around doing 20 hour days trying to get the release out the door. I know just prior to to the last release that Sebastian was re-spinning the release into the early hours of the morning to fix Activity bugs to get the release out the door on time for marketing the day before an exam. If people aren't going to spend the time to make sure their activity works prior to a release there's only only limited time the main people have to do the testing along with all the other release process as well as getting on with the rest of their life. So I think its better we ship with less Activities better tested that cover the core functionality. FWIW, Peter's words resonate with my feelings on this issue, but maybe this change could have been communicated differently (or maybe I'm misunderstanding its ultimate cause). Agreed, it should have been bought up and discussed more openly first but ultimately there's all too few people doing the work and all too many people with an opinion. I feel those actually doing the work should have more say. How I see this issue is that the Sugar community has come to expect the SoaS maintainer(s) to test dozens of activities each release cycle and fix all the issues that may have crept in. Of course, this is an unreasonable expectation and the SoaS team has decided to reduce the scope of their work so it becomes more doable. What the SoaS team could have said instead of we'll ship half a dozen activities, is we have agreed on a criteria for activities that are to be included in a SoaS release. Such a criteria could have been something like: - the activity has been tested and works with the last Sugar release, - the community has voted this activity as sufficiently relevant to be present in SoaS, - the activity has a maintainer that will react to issues with the activity, answer questions, etc. - the activity has been packaged as a rpm and is part of Fedora. I would like to add to this that the activity developer is at least CCed on bugs in Fedora so they can more actively see the issues with their activity and react to the bugs. This may be more effective in tackling with the root cause, which I feel to be unreasonable expectation for the actual resources. The community would understand that the SoaS team currently doesn't have enough resources to include so many activities, and also would feel compelled to find more resources to maintain activities. Agreed. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] SoaS change of direction: heads-up on convos in other lists
What's the reason that Etoys isn't part of the bundle anymore? Are there any technical problems? We do not expect the Sugar developers to fix them. I do like Tomeus suggestions below very much. Rita Von meinem iPhone gesendet Am 22.03.2010 um 10:35 schrieb Tomeu Vizoso to...@tomeuvizoso.net: On Sat, Mar 20, 2010 at 18:10, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 4:54 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Sat, Mar 20, 2010 at 12:46 PM, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 10:26 AM, Sean DALY sdaly...@gmail.com wrote: The problem with this approach is that it renders SoaS ineffective for new tryers of Sugar (i.e. the overwhelming majority of teachers and parents we are trying to reach). I don't think it will be any less ineffective than having 20 activities of which half have issues, crash or just don't run. Are people saying _only 6 activities work reliably?_ My question of which is it? was assuming there are more than 6 that run well, demo well, maintained, etc. So it meant which plan is it, 6 activities that allow downloading and installing of more, or the good ones? If there are only 6 good ones... would focus on making that list longer. Did APIs break with Sugar churn, Fedora churn? Developers upload without testing? (Rethorical! Flamefest warning! Those questions are bound to be a flamefest blaming people who don't deserve to be blamed... :-( ) I think some of or all of the above are to blame. I'm still trying to get time to test. I should do so in the next couple of weeks. Record is one of the classic ones with issues. It was broken horribly for SOAS-2 and possibly even v1 but there's been no real attempt to fix it. Part of it is also that to be in Fedora the precompiled binary crud needs to be removed and in a lot of cases Activity developers don't test it with the native libraries. Also I know Write isn't currently on the list because it doesn't work properly [1] but obviously it would be a good one to have as its a great demo of the collaboration. We also want to get away from the point where a few people are running around doing 20 hour days trying to get the release out the door. I know just prior to to the last release that Sebastian was re-spinning the release into the early hours of the morning to fix Activity bugs to get the release out the door on time for marketing the day before an exam. If people aren't going to spend the time to make sure their activity works prior to a release there's only only limited time the main people have to do the testing along with all the other release process as well as getting on with the rest of their life. So I think its better we ship with less Activities better tested that cover the core functionality. FWIW, Peter's words resonate with my feelings on this issue, but maybe this change could have been communicated differently (or maybe I'm misunderstanding its ultimate cause). How I see this issue is that the Sugar community has come to expect the SoaS maintainer(s) to test dozens of activities each release cycle and fix all the issues that may have crept in. Of course, this is an unreasonable expectation and the SoaS team has decided to reduce the scope of their work so it becomes more doable. What the SoaS team could have said instead of we'll ship half a dozen activities, is we have agreed on a criteria for activities that are to be included in a SoaS release. Such a criteria could have been something like: - the activity has been tested and works with the last Sugar release, - the community has voted this activity as sufficiently relevant to be present in SoaS, - the activity has a maintainer that will react to issues with the activity, answer questions, etc. - the activity has been packaged as a rpm and is part of Fedora. This may be more effective in tackling with the root cause, which I feel to be unreasonable expectation for the actual resources. The community would understand that the SoaS team currently doesn't have enough resources to include so many activities, and also would feel compelled to find more resources to maintain activities. Regards, Tomeu Peter [1] http://bugs.sugarlabs.org/ticket/1767 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] urgent E toy!!!!!!!!!!!
hello Can any one giude how write text in flap connector in Etoy . Its very very urgent -- Kinds Regards Parichay Parivesh +447503433720 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] urgent E toy!!!!!!!!!!!
Everything in Etoys is made from a single kind of basic object. They can all be attached (embedded) in any other object. First, make a flap, then open it by clicking on the tab, and simply drag a text object into the flap and drop it. Cheers, Alan From: Parichay Parivesh parivesh.paric...@googlemail.com To: iaep@lists.sugarlabs.org Sent: Mon, March 22, 2010 4:27:34 AM Subject: [IAEP] urgent E toy!!! hello Can any one giude how write text in flap connector in Etoy . Its very very urgent -- Kinds Regards Parichay Parivesh +447503433720 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists
On Mon, Mar 22, 2010 at 6:12 AM, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Mar 22, 2010 at 9:35 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Sat, Mar 20, 2010 at 18:10, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 4:54 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Sat, Mar 20, 2010 at 12:46 PM, Peter Robinson pbrobin...@gmail.com wrote: On Sat, Mar 20, 2010 at 10:26 AM, Sean DALY sdaly...@gmail.com wrote: The problem with this approach is that it renders SoaS ineffective for new tryers of Sugar (i.e. the overwhelming majority of teachers and parents we are trying to reach). I don't think it will be any less ineffective than having 20 activities of which half have issues, crash or just don't run. Are people saying _only 6 activities work reliably?_ My question of which is it? was assuming there are more than 6 that run well, demo well, maintained, etc. So it meant which plan is it, 6 activities that allow downloading and installing of more, or the good ones? If there are only 6 good ones... would focus on making that list longer. Did APIs break with Sugar churn, Fedora churn? Developers upload without testing? (Rethorical! Flamefest warning! Those questions are bound to be a flamefest blaming people who don't deserve to be blamed... :-( ) I think some of or all of the above are to blame. I'm still trying to get time to test. I should do so in the next couple of weeks. Record is one of the classic ones with issues. It was broken horribly for SOAS-2 and possibly even v1 but there's been no real attempt to fix it. Part of it is also that to be in Fedora the precompiled binary crud needs to be removed and in a lot of cases Activity developers don't test it with the native libraries. Also I know Write isn't currently on the list because it doesn't work properly [1] but obviously it would be a good one to have as its a great demo of the collaboration. We also want to get away from the point where a few people are running around doing 20 hour days trying to get the release out the door. I know just prior to to the last release that Sebastian was re-spinning the release into the early hours of the morning to fix Activity bugs to get the release out the door on time for marketing the day before an exam. If people aren't going to spend the time to make sure their activity works prior to a release there's only only limited time the main people have to do the testing along with all the other release process as well as getting on with the rest of their life. So I think its better we ship with less Activities better tested that cover the core functionality. FWIW, Peter's words resonate with my feelings on this issue, but maybe this change could have been communicated differently (or maybe I'm misunderstanding its ultimate cause). Agreed, it should have been bought up and discussed more openly first but ultimately there's all too few people doing the work and all too many people with an opinion. I feel those actually doing the work should have more say. I don't know if the people actually doing the work should have more say in the discussion itself... it is an open discussion. But certainly the people doing the work should have more say in what decision gets made. In practice, since they are the ones doing the work, they will presumably do what they think is in the best interest of the project. How I see this issue is that the Sugar community has come to expect the SoaS maintainer(s) to test dozens of activities each release cycle and fix all the issues that may have crept in. Of course, this is an unreasonable expectation and the SoaS team has decided to reduce the scope of their work so it becomes more doable. What the SoaS team could have said instead of we'll ship half a dozen activities, is we have agreed on a criteria for activities that are to be included in a SoaS release. Such a criteria could have been something like: - the activity has been tested and works with the last Sugar release, - the community has voted this activity as sufficiently relevant to be present in SoaS, - the activity has a maintainer that will react to issues with the activity, answer questions, etc. - the activity has been packaged as a rpm and is part of Fedora. I would like to add to this that the activity developer is at least CCed on bugs in Fedora so they can more actively see the issues with their activity and react to the bugs. Where my activity developer hat, this would be very useful. I suspect that at least some of the non-responsiveness of developers is due to their not knowing there is a problem in the first place. Also, some of the problems among activities seem to be clustered around specific components, e.g., multimedia support. Ideally, we'd (those who live in the boundary between Sugar and Fedora) have a better handle on these sorts of changes and perhaps be able to come up with some
Re: [IAEP] urgent E toy!!!!!!!!!!!
To get a flap hit CTRLW (on Macintosh CMDW). This will bring up the World menu. Then click on flaps... which will display the flaps menu. Then click on make a new flap You can now drag text (and any other objects) onto the flap. Stephen On Mon, Mar 22, 2010 at 8:42 AM, Alan Kay alan.n...@yahoo.com wrote: Everything in Etoys is made from a single kind of basic object. They can all be attached (embedded) in any other object. First, make a flap, then open it by clicking on the tab, and simply drag a text object into the flap and drop it. Cheers, Alan -- *From:* Parichay Parivesh parivesh.paric...@googlemail.com *To:* iaep@lists.sugarlabs.org *Sent:* Mon, March 22, 2010 4:27:34 AM *Subject:* [IAEP] urgent E toy!!! hello Can any one giude how write text in flap connector in Etoy . Its very very urgent -- Kinds Regards Parichay Parivesh +447503433720 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] urgent E toy!!!!!!!!!!!
Also see http://tracker.squeakland.org/browse/SQ-529 - Bert - On 22.03.2010, at 14:08, Steve Thomas wrote: To get a flap hit CTRLW (on Macintosh CMDW). This will bring up the World menu. Then click on flaps... which will display the flaps menu. Then click on make a new flap You can now drag text (and any other objects) onto the flap. Stephen On Mon, Mar 22, 2010 at 8:42 AM, Alan Kay alan.n...@yahoo.com wrote: Everything in Etoys is made from a single kind of basic object. They can all be attached (embedded) in any other object. First, make a flap, then open it by clicking on the tab, and simply drag a text object into the flap and drop it. Cheers, Alan From: Parichay Parivesh parivesh.paric...@googlemail.com To: iaep@lists.sugarlabs.org Sent: Mon, March 22, 2010 4:27:34 AM Subject: [IAEP] urgent E toy!!! hello Can any one giude how write text in flap connector in Etoy . Its very very urgent ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] urgent E toy!!!!!!!!!!!
Parichay, FYI, just to be clear, it seems from your email you were creating a Button Flap from the Object Catalog. This flap has different properties from the About flap you see on the Etoys home page in that it acts as a Parts Bin The Button Flap allows you to drag objects onto it, so that when you click on an object in the Button Flap it creates a Copy of that object which you can drag onto your World. It seems you wish to create a descriptive or help text flap where you can describe things in the Etoy project. The commands in my previous email explain how to obtain this. We should probably consider adding the text flap to the Object Catalog. Stephen On Mon, Mar 22, 2010 at 9:08 AM, Steve Thomas sthom...@gosargon.com wrote: To get a flap hit CTRLW (on Macintosh CMDW). This will bring up the World menu. Then click on flaps... which will display the flaps menu. Then click on make a new flap You can now drag text (and any other objects) onto the flap. Stephen On Mon, Mar 22, 2010 at 8:42 AM, Alan Kay alan.n...@yahoo.com wrote: Everything in Etoys is made from a single kind of basic object. They can all be attached (embedded) in any other object. First, make a flap, then open it by clicking on the tab, and simply drag a text object into the flap and drop it. Cheers, Alan -- *From:* Parichay Parivesh parivesh.paric...@googlemail.com *To:* iaep@lists.sugarlabs.org *Sent:* Mon, March 22, 2010 4:27:34 AM *Subject:* [IAEP] urgent E toy!!! hello Can any one giude how write text in flap connector in Etoy . Its very very urgent -- Kinds Regards Parichay Parivesh +447503433720 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists
I would like to add to this that the activity developer is at least CCed on bugs in Fedora so they can more actively see the issues with their activity and react to the bugs. Where my activity developer hat, this would be very useful. I suspect that at least some of the non-responsiveness of developers is due to their not knowing there is a problem in the first place. Also, some of the problems among activities seem to be clustered around specific components, e.g., multimedia support. Ideally, we'd (those who live in the boundary between Sugar and Fedora) have a better handle on these sorts of changes and perhaps be able to come up with some recommendations to the activity developers as well., e.g., such and such has changed in F13 so consider using such and such. I agree with some of your points here. There have been cases where I'm aware of things going on upstream that I've been able to advocate and give people information on. One example of this was dracut where it was used for the XO-1.5 rather than cutting a new system. This helps out olpc as its supported upstream. But we also have issues where activities include binary blobs that we are not aware of and hence I have no idea that a change in gstreamer ABI and hence soname will break the Activity because the repoquery command doesn't tell me. I'm quite happy to go through and fix simple breakages like that and assist in the process if I'm aware it will be a problem. I went through a week or two ago and fixed about 12 packages that were broken by the changes in the DSO linker that directly affect SOAS. Also both Sebastian and I have Proven Packager credentials so we can fix other breakages as necessary. I've also seen instances with the bug tracker at bugs.sugarlabs.org where it doesn't seem to assign the bug to a maintainer of an activity. I'm not sure if that's by design or whether it generally does but the bugs I've seen are special cases. It would be great to get the activity developers added as a CC: to the bug reports in the Fedora bugzilla. I strongly suspect that the emails will be very low but at least they can get viability of the issues. I agree that there seems to have been some miscommunication that has lead to some anxiety and mismatched expectations. My understanding is: (1) The SoaS team is trying to position their work as a Fedora spin in order to better leverage the Fedora community processes, with the goal of a system that is easier to maintain and easier for people to contribute. This effort was announced broadly early in the release cycle and has been in the roadmap, but the implications were not necessarily clear to either the SoaS team or the SoaS user community. Of course, the first time is always full of surprises. Yes, and SOAS as a project in general is still young so the process has evolved and changed substantially on each release to date. (2) The recent communications about the spin has been interpreted by the user community (end users and activity developers) as this is what you get when -- tell me if I am wrong -- the real intention is this is where you start. The SoaS team has been trying to communicate the latter of late, but I hope that he is not over committing his time in an unsustainable way. This is where you start is definitely the message that should be pushed. Also a Install and update Activities control panel which uses PackageKit would make it much easier to automatically find and install Activities as well as update them at a later stage. The move to Fedora is also intended to help reduce the workload for all involved. Like the merger of Moblin and Maemo there is a lot of cross over between Sugar and other Fedora projects with very similar underlying core platforms. Gnome/Sugar/Moblin/Meego are all based on telepathy/gstreamer/xulrunner etc and the last 3 are all designed for small platforms (and if you take gnome-mobile into that as well they all are) so they all meld together and the difference ends up being the GUI on top so to be able to utilise all the associated engineering resources to reduce overall load it helps everyone, especially the smaller projects like SOAS. (3) We (Sugar Labs) have not been clear enough in our communications that SoaS is not complete... it is still a work in progress. That said, we do need to make it easy for people to use it or we will never get the feedback we need to make it something that is reliable, maintainable, *and* useful. I think the idea of a baseline spin that is the official Fedora spin as per the roadmap needs to be coupled with a rawhide-like version with many more activities, many of which will not work properly. The key is how to make sure that those using the latter understand that it is experimental and thus they should not expect the degree of support they would get from a spin. The communications out of SugarLabs in general seem to be slowly improving which can only be a good thing. -walter Peter
Re: [IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists
On Mon, Mar 22, 2010 at 9:22 AM, Peter Robinson pbrobin...@gmail.com wrote: I would like to add to this that the activity developer is at least CCed on bugs in Fedora so they can more actively see the issues with their activity and react to the bugs. Where my activity developer hat, this would be very useful. I suspect that at least some of the non-responsiveness of developers is due to their not knowing there is a problem in the first place. Also, some of the problems among activities seem to be clustered around specific components, e.g., multimedia support. Ideally, we'd (those who live in the boundary between Sugar and Fedora) have a better handle on these sorts of changes and perhaps be able to come up with some recommendations to the activity developers as well., e.g., such and such has changed in F13 so consider using such and such. I agree with some of your points here. There have been cases where I'm aware of things going on upstream that I've been able to advocate and give people information on. One example of this was dracut where it was used for the XO-1.5 rather than cutting a new system. This helps out olpc as its supported upstream. But we also have issues where activities include binary blobs that we are not aware of and hence I have no idea that a change in gstreamer ABI and hence soname will break the Activity because the repoquery command doesn't tell me. I'm quite happy to go through and fix simple breakages like that and assist in the process if I'm aware it will be a problem. I went through a week or two ago and fixed about 12 packages that were broken by the changes in the DSO linker that directly affect SOAS. Also both Sebastian and I have Proven Packager credentials so we can fix other breakages as necessary. I've also seen instances with the bug tracker at bugs.sugarlabs.org where it doesn't seem to assign the bug to a maintainer of an activity. I'm not sure if that's by design or whether it generally does but the bugs I've seen are special cases. It would be great to get the activity developers added as a CC: to the bug reports in the Fedora bugzilla. I strongly suspect that the emails will be very low but at least they can get viability of the issues. Not by design, although not every developer requests a component for their project. It would be great if you could file a ticket (assigned to component bugs.sugarlabs.org) when you come across such a situation so a new component can be assigned. Of course, this presumes that someone knows whom is the maintainer. I agree that there seems to have been some miscommunication that has lead to some anxiety and mismatched expectations. My understanding is: (1) The SoaS team is trying to position their work as a Fedora spin in order to better leverage the Fedora community processes, with the goal of a system that is easier to maintain and easier for people to contribute. This effort was announced broadly early in the release cycle and has been in the roadmap, but the implications were not necessarily clear to either the SoaS team or the SoaS user community. Of course, the first time is always full of surprises. Yes, and SOAS as a project in general is still young so the process has evolved and changed substantially on each release to date. (2) The recent communications about the spin has been interpreted by the user community (end users and activity developers) as this is what you get when -- tell me if I am wrong -- the real intention is this is where you start. The SoaS team has been trying to communicate the latter of late, but I hope that he is not over committing his time in an unsustainable way. This is where you start is definitely the message that should be pushed. Also a Install and update Activities control panel which uses PackageKit would make it much easier to automatically find and install Activities as well as update them at a later stage. There is a lot of discussion about this and other approaches to packaging... some movement as well. It will get better. The problem is that there is only a partial overlap between what is currently well maintained and what is needed by the end users and since there is often a issue with network access for our end users, an install and update model will often fail, regardless of the packaging system used. This is why I think it is important to still offer an experimental build that trades reliability and support for variety and inclusiveness. Again, how this is communicated is paramount. The move to Fedora is also intended to help reduce the workload for all involved. Like the merger of Moblin and Maemo there is a lot of cross over between Sugar and other Fedora projects with very similar underlying core platforms. Gnome/Sugar/Moblin/Meego are all based on telepathy/gstreamer/xulrunner etc and the last 3 are all designed for small platforms (and if you take gnome-mobile into that as well they all are) so they all meld
Re: [IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists
On Mon, Mar 22, 2010 at 15:11, Peter Robinson pbrobin...@gmail.com wrote: This is where you start is definitely the message that should be pushed. Also a Install and update Activities control panel which uses PackageKit would make it much easier to automatically find and install Activities as well as update them at a later stage. There is a lot of discussion about this and other approaches to packaging... some movement as well. It will get better. The problem is that there is only a partial overlap between what is currently well maintained and what is needed by the end users and since there is often a issue with network access for our end users, an install and update model will often fail, regardless of the packaging system used. This is why I think it is important to still offer an experimental build that trades reliability and support for variety and inclusiveness. Again, how this is communicated is paramount. WRT to packagekit. The advantage that it has is that it supports .deb and .rpm so what ever the underlying distro is it will work and in the case of the rpm support at least (I don't know enough about the deb integration) you can use locally hosted repos in the case of a school server, and it even support static media such as optical and usb sticks. So it covers a lot more options than just being connected to the internet. WRT the experimental with lots of variety vs the stable with not so much I personally believe there's pros and cons to both approaches. The former is what we've done with previous SOAS releases but we've had the SOAS SUCKS because Activity X doesn't work remarks which isn't good or constructive and its much harder to support for a small core team. The later approach will have I wish there was Activity Y but at least the included Activities should be more stable. In the short term for SOAS-3 there will be the SOAS-3 sucks because previous releases came with Z as well. Basically in the short term we're screwed which ever way. But on the plus side it should give Activity developers incentive to better support their Activities and make them more stable so they'll be considered for inclusion in a later release. The move to Fedora is also intended to help reduce the workload for all involved. Like the merger of Moblin and Maemo there is a lot of cross over between Sugar and other Fedora projects with very similar underlying core platforms. Gnome/Sugar/Moblin/Meego are all based on telepathy/gstreamer/xulrunner etc and the last 3 are all designed for small platforms (and if you take gnome-mobile into that as well they all are) so they all meld together and the difference ends up being the GUI on top so to be able to utilise all the associated engineering resources to reduce overall load it helps everyone, especially the smaller projects like SOAS. The good news is that Collabora is helping Tomeu with a migration of the Sugar Telephany work, so we should be better aligned with the mainstream there come 0.90. We are also working to better leverage gstreamer in order to phase out a dependence on alsa that has causes some of the breakage you've experienced with binary blobs. Re xulrunner, it is a hot topic of discussion right now... Any insights you may have regarding what the future may bring in terms of support and maintainability would be welcome. I'm aware of Tomeu's work. I'm also looking forward to seeing the use of the new component (can't remember what its called) in gstreamer for F-13 in Record to make that more stable. WRT xulrunner I've seen parts of the conversation. I think xulrunner is improving in both speed and memory usage so I'm not sure what the problem is. The next minor release (after the one due this week) will have things like Out Of Process Plugins so that crashing flash etc won't take down it all. Also things like massively improved I/O are helping performance etc. The conversations about discontinuing support for xulrunner are rubbish, and even though the pyxpcom component was split out in the latest major release the xulrunner/firefox guys at redhat have been very helpful to ensure Sugar requirements are met. If there's any thing I've missed in that regard let me know. From the Fedora side, it's true that I haven't heard anything pointing to discontinued support for pyxpcom, but people have mentioned that we may have trouble in Ubuntu-land: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ I don't know how much serious is that, but there are lots of Ubuntu-derivatives used for education, so it would be great if someone could get some kind of official statement (maybe David?). If there's in no push from the community in the Ubuntu side, then maybe the upstream developers should be less concerned about it and expect that PPAs will be used to solve any eventual problems. Thanks, Tomeu Peter ___ IAEP -- It's An Education
Re: [IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists
On Mon, Mar 22, 2010 at 15:24, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Mar 22, 2010 at 2:21 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Mon, Mar 22, 2010 at 15:11, Peter Robinson pbrobin...@gmail.com wrote: This is where you start is definitely the message that should be pushed. Also a Install and update Activities control panel which uses PackageKit would make it much easier to automatically find and install Activities as well as update them at a later stage. There is a lot of discussion about this and other approaches to packaging... some movement as well. It will get better. The problem is that there is only a partial overlap between what is currently well maintained and what is needed by the end users and since there is often a issue with network access for our end users, an install and update model will often fail, regardless of the packaging system used. This is why I think it is important to still offer an experimental build that trades reliability and support for variety and inclusiveness. Again, how this is communicated is paramount. WRT to packagekit. The advantage that it has is that it supports .deb and .rpm so what ever the underlying distro is it will work and in the case of the rpm support at least (I don't know enough about the deb integration) you can use locally hosted repos in the case of a school server, and it even support static media such as optical and usb sticks. So it covers a lot more options than just being connected to the internet. WRT the experimental with lots of variety vs the stable with not so much I personally believe there's pros and cons to both approaches. The former is what we've done with previous SOAS releases but we've had the SOAS SUCKS because Activity X doesn't work remarks which isn't good or constructive and its much harder to support for a small core team. The later approach will have I wish there was Activity Y but at least the included Activities should be more stable. In the short term for SOAS-3 there will be the SOAS-3 sucks because previous releases came with Z as well. Basically in the short term we're screwed which ever way. But on the plus side it should give Activity developers incentive to better support their Activities and make them more stable so they'll be considered for inclusion in a later release. The move to Fedora is also intended to help reduce the workload for all involved. Like the merger of Moblin and Maemo there is a lot of cross over between Sugar and other Fedora projects with very similar underlying core platforms. Gnome/Sugar/Moblin/Meego are all based on telepathy/gstreamer/xulrunner etc and the last 3 are all designed for small platforms (and if you take gnome-mobile into that as well they all are) so they all meld together and the difference ends up being the GUI on top so to be able to utilise all the associated engineering resources to reduce overall load it helps everyone, especially the smaller projects like SOAS. The good news is that Collabora is helping Tomeu with a migration of the Sugar Telephany work, so we should be better aligned with the mainstream there come 0.90. We are also working to better leverage gstreamer in order to phase out a dependence on alsa that has causes some of the breakage you've experienced with binary blobs. Re xulrunner, it is a hot topic of discussion right now... Any insights you may have regarding what the future may bring in terms of support and maintainability would be welcome. I'm aware of Tomeu's work. I'm also looking forward to seeing the use of the new component (can't remember what its called) in gstreamer for F-13 in Record to make that more stable. WRT xulrunner I've seen parts of the conversation. I think xulrunner is improving in both speed and memory usage so I'm not sure what the problem is. The next minor release (after the one due this week) will have things like Out Of Process Plugins so that crashing flash etc won't take down it all. Also things like massively improved I/O are helping performance etc. The conversations about discontinuing support for xulrunner are rubbish, and even though the pyxpcom component was split out in the latest major release the xulrunner/firefox guys at redhat have been very helpful to ensure Sugar requirements are met. If there's any thing I've missed in that regard let me know. From the Fedora side, it's true that I haven't heard anything pointing to discontinued support for pyxpcom, but people have mentioned that we may have trouble in Ubuntu-land: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ I don't know how much serious is that, but there are lots of Ubuntu-derivatives used for education, so it would be great if someone could get some kind of official statement (maybe David?). If there's in no push from the community in the Ubuntu side, then maybe the upstream developers should be less concerned about it and
[IAEP] [ANNOUNCE] Sugar 0.88 release --- status update
Hi, we are 10 days away from the 0.88 release [1]! We are currently in Hard Code Freeze, which means that no source code changes can be made without approval from the release-team. Translation and documentation can continue [2]. See as well [2], on how to request an exception for your show stopper. The hard code freeze ends by March the 29th when the 0.88 tarballs are due. If your fix is not a show stopper but fixes a critical issue, it has good chances to go into the upcoming bug fix release April the 28th. All the other fixes will be moved to 0.90. We will branch directly after the 0.88 release, so development can continue and Features, enhancements and invasive fixes that we moved out can be landed early in the cycle to not be forgotten. What needs to happen in the upcoming week: === Testing === I have gathered some testing plans at [3]. There are instructions on how to get the latest Soas build and put it on stick, and how you can test the latest 0.88 packages on Ubuntu Karmic. Testers are encouraged to leave notes at the wiki page, so we know what has already been tested and what failed. I will send out a daily report now with these results. Of course the bug tracker should be used to report back the findings when testing bugs, too. So we need help in testing and if people step up to coordinate testing and helps to gather test cases etc that would be awesome! === Bugfix, Review === The bugs that are found need to be fixed if possible, reviewed by the module maintainers and finally landed. === Release Notes === The 0.88 Release Notes needs to be finished [4]. === Localization === There is good progress by the localization teams in translating the 0.88 release. Especially New-String-Rich is the 3G Feature, would be nice if we get it 100% translated by next week. @Language Team Heads: Please make sure to push your translations by Monday the 29th of March, so they get included in the tarball. Of course translations after this date will be included in the 0.88.1 Bugfix Release. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule [2] http://wiki.sugarlabs.org/go/Development_Team/Release#Hard_code_freeze [3] http://wiki.sugarlabs.org/go/0.88/Testing [4] http://wiki.sugarlabs.org/go/0.88/Notes ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [GSoC] Sugar Browser
I found this wiki page so far https://wiki.mozilla.org/Mozilla_2/XPCOM_and_Binary_Embedding I should have a chat with the Mozilla people anyway, that page may not be entirely up to date. From this discussion: 1) Performance tests of recent webkit and xulrunner on XOs and other hardware SoaS runs on would be useful, paying close attention to real-world relevance. 2) Regardless of the results of the benchmark, it would be useful to write an abstraction layer over hulahop/pywebkitgtk/whatever would be used for embedding Mozilla 2. It should allow the Sugar browser the ability to switch between engines, if not at runtime at least with very little effort. On 22 March 2010 08:39, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Sun, Mar 21, 2010 at 23:25, Lucian Branescu lucian.brane...@gmail.com wrote: Some have expressed concern about Browse and its current xulrunner dependency (http://bugs.sugarlabs.org/ticket/1850). To make matters even worse for the future, Mozilla plans to get rid of XPCOM at some point in favour of better JavaScript interfacing to C++ and a JavaScript ffi similar to ctypes. The extent up to which xulrunner will be supported by Mozilla as an embeddable engine is the most important point, IMHO. But up to now we only have rumours and speculation. Could someone add a reference to a clear statement or ask someone at Mozilla? Ubuntu's position on this is explained here, though I would prefer something clearer: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/ Surf is an existing browser activity that uses webkit (pywebkitgtk). It is not yet on par feature-wise with Browse, but it could be extended. I see a few possible ways forward, that I could work on for GSoC: 1) Get Browse into shape (with a bundled xulrunner?) 2) Update Surf to be on par with Browse I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. When comparing performance, we need to compare apples to apples, which can be a lot of work. One way to move forward regarding this is to make a simpler Browse comparable in functionality to the current Surf and measure that. While gecko has superior extendability (XUL extensions), Browse isn't compatible with Firefox extensions, so anything would need to be rewritten anyway. Google gears runs unmodified on Browse. Extensions that depend on Firefox interfaces will only run on Firefox, but there are lots of extensions that only use Xulrunner interfaces. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla's Jetpack or Chrome's extensions could be implemented. Second, webkit is being used by a lot of projects and has the backing of several companies. Furthermore, it is packaged more consistently across platforms/distributions. As pointed out above, I think the maintainability issue is the most important here. While we have reasons to fear about Mozilla in this regard, we should act on more final information. Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier. Any thoughts on this? In summary, I think this is a very interesting proposal, thanks for bringing it up again. Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [GSoC] Sugar Browser
FWIW, at litl we are switching from a xulrunner-based brower to a chromium-based browser. We are seeing a big performance improvement, plus it's making it easier for us to implement plugin isolation and better memory management (unloading pages which are not foregrounded, etc). YMMV, and it's been about 3 person-months of work, but I can suggest from experience that it may be worth it. --scott -- ( http://cscott.net/ ) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] urgent E toy!!!!!!!!!!!
I was helping Parichay the last few days and for the life of me could only find two flaps under the Object Catalog: button flap and connectors flap. I find out today from him that in order to add a text flap you have to press ALT , . It's like finding an Easter egg! Hoping that this text flap would be added to the object catalog. Till then, I'll add this to the manual. --Cherry On Mon, Mar 22, 2010 at 6:19 AM, Steve Thomas sthom...@gosargon.com wrote: Parichay, FYI, just to be clear, it seems from your email you were creating a Button Flap from the Object Catalog. This flap has different properties from the About flap you see on the Etoys home page in that it acts as a Parts Bin The Button Flap allows you to drag objects onto it, so that when you click on an object in the Button Flap it creates a Copy of that object which you can drag onto your World. It seems you wish to create a descriptive or help text flap where you can describe things in the Etoy project. The commands in my previous email explain how to obtain this. We should probably consider adding the text flap to the Object Catalog. Stephen On Mon, Mar 22, 2010 at 9:08 AM, Steve Thomas sthom...@gosargon.comwrote: To get a flap hit CTRLW (on Macintosh CMDW). This will bring up the World menu. Then click on flaps... which will display the flaps menu. Then click on make a new flap You can now drag text (and any other objects) onto the flap. Stephen On Mon, Mar 22, 2010 at 8:42 AM, Alan Kay alan.n...@yahoo.com wrote: Everything in Etoys is made from a single kind of basic object. They can all be attached (embedded) in any other object. First, make a flap, then open it by clicking on the tab, and simply drag a text object into the flap and drop it. Cheers, Alan -- *From:* Parichay Parivesh parivesh.paric...@googlemail.com *To:* iaep@lists.sugarlabs.org *Sent:* Mon, March 22, 2010 4:27:34 AM *Subject:* [IAEP] urgent E toy!!! hello Can any one giude how write text in flap connector in Etoy . Its very very urgent -- Kinds Regards Parichay Parivesh +447503433720 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Review this activity
Hello, I have created an activity to teach 3-5 years old kids different mode of transportation, it designed for XO laptop. I have used etoy for scripting. I have upload in squeak show case and I am send the link as well http:// squeakland.org/launcher/?http://squeakland .org/content/showcase/everyone/accounts/pariveshp /GOING%20ON%20A%20RIDE%20GAME%20Final.pr please have look and mail me your review. Your review is very important for me because I have to put into my report. -- Kinds Regards Parichay Parivesh +447503433720 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [GSoC] Sugar Browser
On Mon, Mar 22, 2010 at 5:42 PM, C. Scott Ananian csc...@cscott.net wrote: FWIW, at litl we are switching from a xulrunner-based brower to a chromium-based browser. We are seeing a big performance improvement, plus it's making it easier for us to implement plugin isolation and better memory management (unloading pages which are not foregrounded, etc). YMMV, and it's been about 3 person-months of work, but I can suggest from experience that it may be worth it. The two main issues with chromium is its upstreamability, which becomes a problem for at least Fedora and Debian, and actually having the resources to dedicated to it. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar Digest 2010-03-22
==Sugar Digest== 1. LIBREPLANET was this past weekend. It was held that the Harvard University Science Center and drew a large crowd of FLOSS movers and shakers. RMS was there. He spoke about the risks that Software as a Service poses to our freedoms. I unfortunately missed John Gilmore's talk, where he outlined what he thinks are the next goals for the community. It is no surprise that Eben Moglen gave an inspiring talk. He spoke about how much we have accomplished: Free Software is no longer an option; it is indispensable. We talked about some of the opportunities, especially in education, afforded by software that is reliable and has a unit cost of zero. I spoke briefly with Brewster Kahle about how we might further leverage the Internet Archive. It has a wealth of materials of potential interest to Sugar users (For example, I just forwarded this link to the Sur list as I thought it was a nice complement to some of the geometry problems they had been discussing [http://ia331304.us.archive.org/2/items/amusementsinmath16713gut/16713-h/16713-h.htm#GREEK_CROSS_PUZZLES]). I attended a talk given by some members of GNU Generation [http://fsf.org/gnugeneration]. They are a group of pre-university students involved in FLOSS development. Sugar Labs has great synergy with this group; I have already tried to connect them with Jeff Elkner's team at Sugar Labs DC. I also met Asheesh Laroia from Open Hatch [http://openhatch.org]. Open Hatch is a place to find volunteer opportunities and volunteers. Asheesh was kind enough to add the sugar-love tag on bugs.sugarlabs.org to the Open Hatch volunteer opportunities list. I noticed that both Sebastian Dziallas and Mel Chua are new to Open Hatch as well. They have done a nice job of describing Sugar and Sugar on a Stick. The title of my talk was Beyond 'open': Making software easier to modify. I began by showing two photos that Bernie Innocenti took in Caacupe, Paraguay. Pictures of smiling children with computer is always a hit, but chose my pictures carefully. The first photo was of two young girls hiding behind their OLPC XO-1 laptops. The laptops had been covered (end-user customized) with stickers ''despite'' the best efforts of the designer. (The XO has bumps on its surface that in order to hide scratches and deter the use of stickers.) The second photo was of two young boys replacing broken displays. In this case the design goal was to enable the end user to make repairs (if not modifications) to the hardware. I then quoted Eben completely out of context. He had said in the talk prior to mine that only Free Software had achieved the elusive goal of being write once, run everywhere. I said that Sugar had a different goal. We want our code to be written over and over again by our end users because they will learn in the process. Of course we want to write reliable code that will enable Sugar to run everywhere and in fact, we have made great progress in this regard over the past two years, in part by hanging onto the coattails of the GNU/Linux community's efforts. I tried to make the point that the usual metrics — robustness, efficiency, maintainability, etc. — are not enough for education. We need to go a step further by ensuring that our code is free and open but also practically amenable to manipulation. (The license guarantees that all Free Software can be modified by the end user, but for most users, this is just a theoretical freedom.) If everyone learns to write code and if more code is written with end-user modifications in mind, we will have a world in which everyone is engaged in debugging, what Cynthia Solomon described as the great educational opportunity of the 21st Century. At this point, I meant to digress. In the mid-to-late 1980s, I worked on digital video systems. The standard metrics used by the engineering community at the time were complexity of encoding, channel robustness, complexity of decoding, and, of course, the compression ratio. I tried to introduce a fifth metric: the degree to which the encoded signal was amenable to manipulation by the end user. I had in mind simple things like remixing, which had implications regard to the mix of I-, P-, and B-frames in MPEG. I didn't want us to repeat the mistakes of SÉCAM, in which cannot easily be edited in its native analog form. (I forgot to make this digression in the actual talk.) I went on to describe some of the approaches we have taken at Sugar Labs to encourage and facilitate end-user modifications: * Setting expectations: establishing a culture in which it is the norm to exercise the freedoms afforded by Free Software; * Free Software: articulating the free modify aspect of Free Software (Freedom 1); * View Source: provide tools that make it easy to access the source; * Scripting languages: use scripting languages (Python, Javascript, and Smalltalk in the case of Sugar) so that changes can be direct and immediate; * Small steps: provide a scaffolding to enable the end user to get
Re: [IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists
Hello All, In wanting to have Teachers and Developers try Sugar are best bet may be to attack this with a two-fold approach. The idea would be to give the prospective Teacher/Deployer Two SoaS-A stable version-say Strawberry explaining exactly what Sugar Labs means by Stable. Then the Newer Developer edition Mirabelle that allows them to test and be part of the Future Research and Development portion of Sugar. This would seem to get around many of the issues and draw support for stable and cutting edge versions. Sugar Today-Sugar Tomorrow 2Pack-Add in SoaS Creation Kit with both images and Instructions and we could have something very helpful to all participants. If this route is chosen then the Developer release of Mirabelle should have many of the broken activities. These broken activities would seem to be a perfect place for many new community members to get acquainted with Sugar(Testing, Learning the Bug reporting system, Fixing activities). Activities are at the core of the Learning How To Learn portion of the Sugar Learning Platform so the appropriate level of resources making sure the communication is in place to keep them maintained should be of key focus, since it will be one the largest keys to our success in the classroom. Best! John Tierney Date: Mon, 22 Mar 2010 15:35:14 +0100 From: to...@tomeuvizoso.net To: pbrobin...@gmail.com CC: martin.langh...@gmail.com; m...@melchua.com; market...@lists.sugarlabs.org; walter.ben...@gmail.com; iaep@lists.sugarlabs.org; s...@sugarlabs.org Subject: Re: [Marketing] [IAEP] SoaS change of direction: heads-up on convos in other lists On Mon, Mar 22, 2010 at 15:24, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Mar 22, 2010 at 2:21 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Mon, Mar 22, 2010 at 15:11, Peter Robinson pbrobin...@gmail.com wrote: This is where you start is definitely the message that should be pushed. Also a Install and update Activities control panel which uses PackageKit would make it much easier to automatically find and install Activities as well as update them at a later stage. There is a lot of discussion about this and other approaches to packaging... some movement as well. It will get better. The problem is that there is only a partial overlap between what is currently well maintained and what is needed by the end users and since there is often a issue with network access for our end users, an install and update model will often fail, regardless of the packaging system used. This is why I think it is important to still offer an experimental build that trades reliability and support for variety and inclusiveness. Again, how this is communicated is paramount. WRT to packagekit. The advantage that it has is that it supports .deb and .rpm so what ever the underlying distro is it will work and in the case of the rpm support at least (I don't know enough about the deb integration) you can use locally hosted repos in the case of a school server, and it even support static media such as optical and usb sticks. So it covers a lot more options than just being connected to the internet. WRT the experimental with lots of variety vs the stable with not so much I personally believe there's pros and cons to both approaches. The former is what we've done with previous SOAS releases but we've had the SOAS SUCKS because Activity X doesn't work remarks which isn't good or constructive and its much harder to support for a small core team. The later approach will have I wish there was Activity Y but at least the included Activities should be more stable. In the short term for SOAS-3 there will be the SOAS-3 sucks because previous releases came with Z as well. Basically in the short term we're screwed which ever way. But on the plus side it should give Activity developers incentive to better support their Activities and make them more stable so they'll be considered for inclusion in a later release. The move to Fedora is also intended to help reduce the workload for all involved. Like the merger of Moblin and Maemo there is a lot of cross over between Sugar and other Fedora projects with very similar underlying core platforms. Gnome/Sugar/Moblin/Meego are all based on telepathy/gstreamer/xulrunner etc and the last 3 are all designed for small platforms (and if you take gnome-mobile into that as well they all are) so they all meld together and the difference ends up being the GUI on top so to be able to utilise all the associated engineering resources to reduce overall load it helps everyone, especially the smaller projects like SOAS. The good news is that Collabora is helping Tomeu with a migration of the Sugar Telephany work, so we should be better aligned with the mainstream there come 0.90. We are also working to better leverage gstreamer in order to phase out a dependence on alsa
