Re: [Sugar-devel] Activity Central's Sugar related priorities.
Hi! Took some time but finally set up my git account... 2 Journal This is probably the issue we have been most aware of. I've been thinking in the per activity datastore direction too and I think it's probably the best one. Though as you say that involves UI redesign and we would need to figure out compatibility with existing activities. (Please share the webkit code, I don't know if I'll have time to hack on it but I did think to write something like that at some point, it would be interesting to look at it if nothing else). I have put the ?latest? sources here: https://github.com/NoiseEHC/sugar-webkit-native It requires a yum install webkitgtk3-devel to be able to compile, unfortunately my XO-1.75 says that there are no more mirrors to try for mesa and libdrm dependencies so I could not try it under an ARM XO... (I did try it some time ago however it just stopped working.) You may also need to create a test2/bin directory as git does not include it... The code is full of static char buffers which should be fixed and it also crashes on an XO when you compile with webkit2gtk... We probably all agree that it would be awesome to have something that integrates well with Sugar and works transparently by reusing existing web technologies. I don't think that's easy to achieve though. It has been said in previous discussions that without the close integration between activities and system, Sugar would be just yet another suite of educational applications (and likely not the best of them). I very much agree and I think it's tricky to preserve that while moving to frameworks which are supposed to work everywhere. We could have started with something more web developer friendly and incrementally integrated it into the native Sugar platform, for example by redesigning the Journal in the way you described, and somehow adapting native activities to the new design. Instead we went for something targeted at the current Sugar developers with the idea of making it incrementally more web friendly. I have been on the fence on what was the best approach and I still am. Something to consider is that we barely have the resources to maintain the existing native code. I doubt, for example, that we would be able to ship a redesigned Journal. Consider also that the people most involved with this work has all a good knowledge of the Sugar platform but are not really web developers. I fail to see why would it be bad if Sugar would be just yet another suite of educational applications. Currently the close integration between activities and system consist only of 3 DBUS methods, 4 X properties, the Journal as a filesystem and the presence service (which is desugarized if I remember correctly, you have to use Telepathy directly?). In my opinion the single most important thing would be to allow developing sugar applications directly in the PC browser (like firefox or chrome). If that would work then you could just go to a web conference and after giving a presentation about sugar-web you could ask the attended crowd to help you in the workshop by converting just ONE/person python activity into a web one and you are done with the conversion in a day... Obviously it would not make converting Write/TurtleArt/Etoys/Scratch easy but at least the rest would be done. Now, if you go standard web, then you do not need the X properties, view-source is built into the browser (DBUS HandleViewSource) and DBUS SetActive can be done with webkitvisibilitychange event and timers. The only remaining thing would be handling the DBUS Invite. Collaboration would most likely need an OT library which should have a C implementation on the XO to have usable speed. The Journal simply can be implemented by the host application by providing either some standard file API implementation (like light-swift) or just providing a virtual page with links and POST. https://github.com/bancek/light-swift So if you already run a node.js server then probably it could host the activity's html files and could provide some virtual file GET/POST service in http://localhost/journal/directory.json - this is for file list http://localhost/journal/guidcomeshere - this is for GET/POST files My plan was to support http://localhost directly from sugar-webkit-native (instead using file:// to be able to OAuth) and query/update the journal from there too but it is simpler from node.js if you are running it anyways. You can also assume that web developers have node.js running on their dev machine or already know how to install it. If you forget for a while to have collaboration from web apps then the rest can be done in no time IMHO. So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. Regards, Andrew ___ Devel mailing list Devel@lists.laptop.org
Re: [Sugar-devel] Activity Central's Sugar related priorities.
So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. What I really don't understand is, if is all that easy why not be involved and help? The development of the web activities stuff was done in the open, mostly by two developers, manuq dnarvaez. Then everyone who wanted help, could do it. Say now how should be done, is useless at least. Talk is easy... as always, the devil is in the details. But you already know that, if not would not talk about unconstructive criticism Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
I have put the ?latest? sources here: https://github.com/NoiseEHC/sugar-webkit-native It requires a yum install webkitgtk3-devel to be able to compile, unfortunately my XO-1.75 says that there are no more mirrors to try for mesa and libdrm dependencies so I could not try it under an ARM XO... (I did try it some time ago however it just stopped working.) You may also need to create a test2/bin directory as git does not include it... The code is full of static char buffers which should be fixed and it also crashes on an XO when you compile with webkit2gtk... Ehem, the source should be in a directory called test2 so it matches the name in the .info file... That is why it requires a test/bin subdir... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 22/10/2013 21:21, Gonzalo Odiard wrote: So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. What I really don't understand is, if is all that easy why not be involved and help? The development of the web activities stuff was done in the open, mostly by two developers, manuq dnarvaez. Then everyone who wanted help, could do it. Say now how should be done, is useless at least. Talk is easy... as always, the devil is in the details. But you already know that, if not would not talk about unconstructive criticism Gonzalo You are right. The problem is that my views are exactly the opposite of the decided path to take. I do not help developing because I totally oppose the current path, meaning that I do not believe that it can work. All the easy talk can be useful later *if* they decide to change paths. Or it will just remain an interesting viewpoint, but at least I tried. So while you are right about the Talk is easy part as well, I could only help developing by finishing the native webkit app (because I believe in it), which would be totally wasted (parallel) effort. Actually that was the plan but then I run out of time and realized that the official project went a different direction anyway. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
Hi NoiseEHC, No, it won't... It already happened when Bryan Berry moved OLPC Nepal's lessons from EToys to Flash, then to HTML5 and there were not any more contributors. I mean, there are much more JS developers, so if you pay them you can get cheaper talent, but there will be not too much more contributors IMHO. The problem is that the current HTML5 work goes into a direction which I am not sure that needed by anyone other than existing Sugar developers. Well we are trying to go in the direction you mention below, that is standard web development. So thanks for jumping in. It all boils down to this simple question: If you are a potential contributor wanting to develop some educational activity (not a framework but some concrete lesson or stuff usable in a lesson!!!) then which one would you use? 1. A HTML5 + JavaScript activity model called Sugar Web Activity, which reaches 2-3 million children? (lets call it SWA) 2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which reaches 1 billion children? (lets call it WEB) I have not seen any compelling reason why would a potential contributor (software developer from a developed country who has/likes children) choose option 1 instead of 2... Yes, option two... ideally. We should tend to zero Sugar specific functionallities. I think it is a good compromise what we did: start from simple web activities that already work side by side with GTK ones, and tend to standard webapps. Now I will not give you constructive criticism as that would allow answering that I should not tell others what to do and it would be getting old... Instead here is some nonconstructive criticism: I think each of the following items deserve a thread on its own. Feel free to continue discussion. Some months ago I wanted to create a sample activity to present my point but I have run out of time so unfortunately I cannot show it to you. It would have been a Google Drive backed game with shared state (so the same as a typical shared activity in Sugar) called Scrabble what I try to port to SWA. It uses the following things which are trivial to use on the WEB but cannot be found in SWA: As far as I understand, Google Drive is an online service. Please note that we are targetting offline webapps, as Sugar is meant to work without an Internet connection. Of course it is not forbidden. And Drive could be a nice datastore backend. But not the only one. 1. Sign in. There is no authorization API in SWA so using anything than the local journal is problematic. Using Google's OAuth authentication from a file:// protocol is impossible so if you want to support existing code then you have to serve the activity from http://localhost... https://developers.google.com/drive/about-auth Daniel gave a good reply to this one. 2. Datastore. There is no way to access the Google Drive if you cannot authenticate. I do not see why would anyone use a new JavaScript lib which accesses only the journal when they are already familiar with some WEB technology. Like WEBDAV or the OpenStack's SWIFT API. http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html Nice. Reading about the WebDAV protocol and OpenStack SWIFT API. Or simply using POST for uploading: https://developers.google.com/drive/manage-uploads Yeah, good point. 3. Collaboration. Using the Google Drive Realtime API is dead simple. It is the most missing feature from SWA BTW. https://developers.google.com/drive/realtime/ Interesting. It requires Internet. I have looked at several open source Operational Transformations libraries but did not have time to test their performance on an XO... 4. Using WebSockets for simple tasks. The autosaving can be implemented by the almost standard webkitvisibilitychange event (but you have to compile webkit with the appropriate parameters) and standard timers. Activity startup is simplified with per activity data store (POST-ing to the same server is the default on the WEB). I think it eliminates the communication with Sugar so no need for WebSockets... 5. Android port. There already exists a multi-platform technology called PhoneGap. It can target 100-200 million children so it can be called option 3 if you want... It can become obsolete as HTML5 provides more and more of its features though. http://phonegap.com/ So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform. Of course that would require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors otherwise everybody will go with Google APIs which cannot easily be emulated on an XO machine... So, running and using those servers is what
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 07/10/2013 18:41, David Farning wrote: Activity Central supports the recent HTML5 + JS work that is going into sugar .100. It has the potential to take the OLPC vision to any device which runs a browser while simultaneously *increasing* the potential activity *developer* *pool* by several orders of magnitude. This is an excellent area for community lead research. Activity Central will be doing activity side work to test the viability of the framework for client deployments. No, it won't... It already happened when Bryan Berry moved OLPC Nepal's lessons from EToys to Flash, then to HTML5 and there were not any more contributors. I mean, there are much more JS developers, so if you pay them you can get cheaper talent, but there will be not too much more contributors IMHO. The problem is that the current HTML5 work goes into a direction which I am not sure that needed by anyone other than existing Sugar developers. It all boils down to this simple question: If you are a potential contributor wanting to develop some educational activity (not a framework but some concrete lesson or stuff usable in a lesson!!!) then which one would you use? 1. A HTML5 + JavaScript activity model called Sugar Web Activity, which reaches 2-3 million children? (lets call it SWA) 2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which reaches 1 billion children? (lets call it WEB) I have not seen any compelling reason why would a potential contributor (software developer from a developed country who has/likes children) choose option 1 instead of 2... Now I will not give you constructive criticism as that would allow answering that I should not tell others what to do and it would be getting old... Instead here is some nonconstructive criticism: Some months ago I wanted to create a sample activity to present my point but I have run out of time so unfortunately I cannot show it to you. It would have been a Google Drive backed game with shared state (so the same as a typical shared activity in Sugar) called Scrabble what I try to port to SWA. It uses the following things which are trivial to use on the WEB but cannot be found in SWA: 1. Sign in. There is no authorization API in SWA so using anything than the local journal is problematic. Using Google's OAuth authentication from a file:// protocol is impossible so if you want to support existing code then you have to serve the activity from http://localhost... https://developers.google.com/drive/about-auth 2. Datastore. There is no way to access the Google Drive if you cannot authenticate. I do not see why would anyone use a new JavaScript lib which accesses only the journal when they are already familiar with some WEB technology. Like WEBDAV or the OpenStack's SWIFT API. http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html Or simply using POST for uploading: https://developers.google.com/drive/manage-uploads 3. Collaboration. Using the Google Drive Realtime API is dead simple. It is the most missing feature from SWA BTW. https://developers.google.com/drive/realtime/ I have looked at several open source Operational Transformations libraries but did not have time to test their performance on an XO... 4. Using WebSockets for simple tasks. The autosaving can be implemented by the almost standard webkitvisibilitychange event (but you have to compile webkit with the appropriate parameters) and standard timers. Activity startup is simplified with per activity data store (POST-ing to the same server is the default on the WEB). I think it eliminates the communication with Sugar so no need for WebSockets... 5. Android port. There already exists a multi-platform technology called PhoneGap. It can target 100-200 million children so it can be called option 3 if you want... It can become obsolete as HTML5 provides more and more of its features though. http://phonegap.com/ So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform. Of course that would require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors otherwise everybody will go with Google APIs which cannot easily be emulated on an XO machine... But as this discussion already happened and I have already written enough now, I just finish here. (In the following link you can replace the phrase Per Activity Data Store with Standard WEB Storage to be relevant...) http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html Thank you for your attention! Andrew ps: Now to say something constructive as well, some more words about the Journal. Recently I was watching one of Walter Bender's talks where he was
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 9 October 2013 22:51, NoiseEHC noise...@gmail.com wrote: Now I will not give you constructive criticism as that would allow answering that I should not tell others what to do and it would be getting old... Instead here is some nonconstructive criticism: I don't know if it's constructive or not, but I'd say it's certainly useful. You are identifying the major limitations of the current sugar-web framework. Just some notes about them. 1 Inability to do OAuth This has been discussed for Firefox OS too and as far as I know there is no good solution for it yet. I won't claim to understand all the security implications, tough the basic issue seems to run content from the web inside an higher privileged application. In our case it's worst because we don't support hosted web applications at all. 2 Journal This is probably the issue we have been most aware of. I've been thinking in the per activity datastore direction too and I think it's probably the best one. Though as you say that involves UI redesign and we would need to figure out compatibility with existing activities. (Please share the webkit code, I don't know if I'll have time to hack on it but I did think to write something like that at some point, it would be interesting to look at it if nothing else). 3 Collaboration One of the reasons we haven't tackled it yet is that we think something like what you proposed might be a better solution than trying to wrap the current native framework (which is also known to be very unreliable). So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform. We probably all agree that it would be awesome to have something that integrates well with Sugar and works transparently by reusing existing web technologies. I don't think that's easy to achieve though. It has been said in previous discussions that without the close integration between activities and system, Sugar would be just yet another suite of educational applications (and likely not the best of them). I very much agree and I think it's tricky to preserve that while moving to frameworks which are supposed to work everywhere. We could have started with something more web developer friendly and incrementally integrated it into the native Sugar platform, for example by redesigning the Journal in the way you described, and somehow adapting native activities to the new design. Instead we went for something targeted at the current Sugar developers with the idea of making it incrementally more web friendly. I have been on the fence on what was the best approach and I still am. Something to consider is that we barely have the resources to maintain the existing native code. I doubt, for example, that we would be able to ship a redesigned Journal. Consider also that the people most involved with this work has all a good knowledge of the Sugar platform but are not really web developers. Just my $0.02. Manuel might want to post his perspective too. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 10 October 2013 00:22, Daniel Narvaez dwnarv...@gmail.com wrote: 1 Inability to do OAuth This has been discussed for Firefox OS too and as far as I know there is no good solution for it yet. I won't claim to understand all the security implications, tough the basic issue seems to run content from the web inside an higher privileged application. In our case it's worst because we don't support hosted web applications at all. I don't fully understand the problems involved yet but mozilla seems to have a found a solution to this https://bugzilla.mozilla.org/show_bug.cgi?id=852720 We do have a stable origin already given by the app:// protocol we are using. Though I'm not sure that's the only requirement (the discussion on the bug report is long and a bit confusing). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
Excuse the top post: FWIW, I have most of a Sugar authentication with Google Drive working. (For the almost finished Gdrive webservice.) -walter On Wed, Oct 9, 2013 at 8:04 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 October 2013 00:22, Daniel Narvaez dwnarv...@gmail.com wrote: 1 Inability to do OAuth This has been discussed for Firefox OS too and as far as I know there is no good solution for it yet. I won't claim to understand all the security implications, tough the basic issue seems to run content from the web inside an higher privileged application. In our case it's worst because we don't support hosted web applications at all. I don't fully understand the problems involved yet but mozilla seems to have a found a solution to this https://bugzilla.mozilla.org/show_bug.cgi?id=852720 We do have a stable origin already given by the app:// protocol we are using. Though I'm not sure that's the only requirement (the discussion on the bug report is long and a bit confusing). ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 8 October 2013 01:45, Ruben Rodríguez ru...@activitycentral.com wrote: Also, there are some bits of code in both Sugar and the activities that assume to be running on Fedora, or even on an XO, and those need cleaning. Please fix those bits directly upstream! I have not seen any patch related to this effort yet. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, Oct 7, 2013 at 6:07 PM, Samuel Greenfeld greenf...@laptop.org wrote: This actually is kind of what I meant (and perhaps should be a separate thread). My understanding is that deployments nowadays are the primary parties funding Sugar development. And the deployments or their contractors sometimes duplicate work, run into debates upstreaming things, and/or may choose to keep some things semi-private to differentiate their products. So apart from major functionality like HTML5 activities, a lot of peripheral development is happening downstream-first. And when we do try to do major cross-group development like the GTK3 port, this has lead to finger-pointing behind the scenes where it is claimed others are not doing what they promised. To the best of my knowledge no single organization currently employs enough developers and/or contractors to keep Sugar development alive. I am not certain what the best approach to take is when this is the case. Thanks to everyone for their feedback on this thread. As Samuel points out, over the last several years, the ecosystem has evolved from a single entity into a number of organisations with overlapping, but not identical, goals. This opens the door for a competitive ecosystem such as the kernel which thrives by making it more effective to compete on top of a collaboratively developed foundation rather than going it alone. In this case, I don't know how the upstream / downstream relationship will look. My feeling is that it will require us as individuals and organizations to look at how we currently benefit (and struggle) by competing and how we can set aside our egos and benefit by collaborating. In the coming weeks, Ruben and Anish will be available on the mailing lists and at the conference in San Francisco to discuss if working together is mutually desirable. From there, we can go in to the technical aspects of how to make that happen. On Mon, Oct 7, 2013 at 6:22 PM, James Cameron qu...@laptop.org wrote: On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote: Well everyone seems to be developing their own version of Sugar seems to be more than that. But maybe I'm just reading too much into it. There aren't multiple groups of people or individuals developing sugar on their own. As far as I know all the work that is being done these days is going upstream. Good. I only know of four Sugars. Sugar upstream, Dextrose, what is in OLPC OS, and what is in the Australian builds. There might be more, but I'm not aware of them. I also don't know the difference between each. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- David Farning Activity Central: http://www.activitycentral.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 7 October 2013 19:24, Samuel Greenfeld greenf...@laptop.org wrote: - Updating the Sugar release in Ubuntu sounds like something everyone could benefit from, not just Dextrose users. Is there any reason not to base most of this work starting with upstream Sugar existing Ubuntu packages? +1 - In general one of my frustrations lately is that now that we no longer publicly review patches on this mailing list, everyone seems to be developing their own version of Sugar. Can you elaborate on this one? I haven't noticed this kind of change (and we have not been reviewing most patches on the mailing list since a long long time, well before the github switch). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 7 October 2013 18:41, David Farning dfarn...@activitycentral.com wrote: Would either of these list be appropriate to continue these discussions about this downstream efforts to port sugar to Ubuntu for use on hardware not sold by the Association? Phase one has been a poof of concept as seen at http://wiki.sugarlabs.org/go/Ubuntu (ongoing) Phase two will be opening the project to the community. Phases three will be testing and piloting by deployments. I would like to understand better what you mean with porting. It should just be matter of writing package specs (or really fixing the existing ones...), no? If there is any more work involved strongly suggest you first discuss it on this mailing list, then have it done upstream directly. That way the whole community will benefit from your effort and you will benefit from the community input. Upstreaming after the fact rarely works. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
In general one of my frustrations lately is that now that we no longer publicly review patches on this mailing list, everyone seems to be developing their own version of Sugar. Can you elaborate on this one? I haven't noticed this kind of change (and we have not been reviewing most patches on the mailing list since a long long time, well before the github switch). I think the change was the movement to github. If we can add sugar-devel mailing list to the github mail destinations, that can be solved. Gonzalo ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Monday, 7 October 2013, Gonzalo Odiard wrote: In general one of my frustrations lately is that now that we no longer publicly review patches on this mailing list, everyone seems to be developing their own version of Sugar. Can you elaborate on this one? I haven't noticed this kind of change (and we have not been reviewing most patches on the mailing list since a long long time, well before the github switch). I think the change was the movement to github. If we can add sugar-devel mailing list to the github mail destinations, that can be solved. I was mostly concerned about Samuel feeling that everyone is developing they're own version of Sugar. I don't see that or at least I don't see differences with the past. We probably can have sugar-devel as email destination... Though I'm not sure why people wouldn't just watch the modules they are interested in? It seems more flexible. Anyway not opposed to send all modules to the whole mailing list if there is consensus on that. -- Daniel Narvaez ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, Oct 7, 2013 at 3:58 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 7 October 2013 18:41, David Farning dfarn...@activitycentral.comwrote: Would either of these list be appropriate to continue these discussions about this downstream efforts to port sugar to Ubuntu for use on hardware not sold by the Association? Phase one has been a poof of concept as seen at http://wiki.sugarlabs.org/go/Ubuntu (ongoing) Phase two will be opening the project to the community. Phases three will be testing and piloting by deployments. I would like to understand better what you mean with porting. It should just be matter of writing package specs (or really fixing the existing ones...), no? I agree. Have Sugar working on Ubuntu would be great, but would be mainly: * Solve dependencies in ubuntu (update/fix packages) * Make Sugar work with other dependencies when is not possible. In the first case, upstream is Ubuntu, in the second case, upstream is Sugarlabs. In both cases, working with upstream is the best solution in the long run, while I understand for Dextrose is useful have some exclusive features, I hope you avoid the shortcut and plan thinking in the future. Gonzalo If there is any more work involved strongly suggest you first discuss it on this mailing list, then have it done upstream directly. That way the whole community will benefit from your effort and you will benefit from the community input. Upstreaming after the fact rarely works. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, Oct 7, 2013 at 12:41 PM, David Farning dfarn...@activitycentral.com wrote: As a more incremental approach, Activity Central will continue our deployment-centric work by porting Dextrose to Ubuntu. From a deploy to XOs PoV that sounds like a ton of work. You'll grind against a lot of little problems. Fedora is no longer behind nor problematic. That was very much true in earlier times. Some innovative things in Fedora (ie: systemd) have been very well integrated with the Sugar stack. And some changes in the Ubuntu pipeline are likely to cause some havoc. From a work for AC customers already using Ubuntu, it probably makes more sense. Still, the odd directions Ubuntu seems to be going are a bit of a wildcard. I honestly hope that they settle a bit and make life for their downstreams a bit easier. cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
I agree with Martin on the odd directions Ubuntu is exhibiting; it may be safer to target Debian instead, from which support for Ubuntu will generally follow. (On the other hand, I lack evidence to agree with claims about the stability or direction of Fedora. So few people I know use it.) -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
Daniel Narvaez wrote: Gonzalo Odiard wrote: Daniel wrote: Gonzalo Odiard wrote: Samuel Wrote: In general one of my frustrations lately is that now that we no longer publicly review patches on this mailing list, everyone seems to be developing their own version of Sugar. Can you elaborate on this one? I haven't noticed this kind of change (and we have not been reviewing most patches on the mailing list since a long long time, well before the github switch). I think the change was the movement to github. If we can add sugar-devel mailing list to the github mail destinations, that can be solved. I was mostly concerned about Samuel feeling that everyone is developing they're own version of Sugar. I don't see that or at least I don't see differences with the past. I agree with Samuel; that with the loss of public review of patches participation in development has been confined to those who take the trouble to visit a web site. (The reviews by mail were also stimulating other discussion on list). So on the theory that developers are developing with less review (even though it might be unseen greater review), this leads to the conclusion that Sugar is being developed by these developers on their own. And, actually, I'm fine with that. A smaller group can achieve more if they are able to use these new tools effectively. I have not been effective since that change, but you would have seen that a review counter or tracking? Has there been a measure of review rate? We probably can have sugar-devel as email destination... Though I'm not sure why people wouldn't just watch the modules they are interested in? It seems more flexible. Anyway not opposed to send all modules to the whole mailing list if there is consensus on that. I don't see how watching the modules they are interested in is more flexible, nor whether greater flexibility increases the communication. Please don't configure github to send links to the patches; they have to be the patches themselves. They should also have a from address that matches the originator. What used to happen was easy. Get a mail with the patch. Scroll it down while reviewing it. When the cognitive dissonance hits a threshold, hit the reply button and begin a comment. Press send. Mail is a store and forward architecture. I can use mail without having to wait for an internet connection. Github is not so lucky: $ ping -n github.com rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 7 October 2013 23:39, James Cameron qu...@laptop.org wrote: I agree with Samuel; that with the loss of public review of patches participation in development has been confined to those who take the trouble to visit a web site. (The reviews by mail were also stimulating other discussion on list). So on the theory that developers are developing with less review (even though it might be unseen greater review), this leads to the conclusion that Sugar is being developed by these developers on their own. Well everyone seems to be developing their own version of Sugar seems to be more than that. But maybe I'm just reading too much into it. There aren't multiple groups of people or individuals developing sugar on their own. As far as I know all the work that is being done these days is going upstream. And, actually, I'm fine with that. A smaller group can achieve more if they are able to use these new tools effectively. I have not been effective since that change, but you would have seen that a review counter or tracking? I can't parse this question. Has there been a measure of review rate? We usually have 1 reviewer per patch. All the patches that have been submitted so far has been reviewed and landed. We probably can have sugar-devel as email destination... Though I'm not sure why people wouldn't just watch the modules they are interested in? It seems more flexible. Anyway not opposed to send all modules to the whole mailing list if there is consensus on that. I don't see how watching the modules they are interested in is more flexible, nor whether greater flexibility increases the communication. Because if we send patches to the mailing I'm pretty sure some people will be annoyed. In fact someone got annoyed when he was added to the reviewers group and started getting email. Please don't configure github to send links to the patches; they have to be the patches themselves. They should also have a from address that matches the originator. I highly doubt what you want is possible, at least without doing substantial work... If you have time feel free. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
2013/10/7 James Cameron qu...@laptop.org: Daniel Narvaez wrote: Gonzalo Odiard wrote: Daniel wrote: Gonzalo Odiard wrote: Samuel Wrote: In general one of my frustrations lately is that now that we no longer publicly review patches on this mailing list, everyone seems to be developing their own version of Sugar. Can you elaborate on this one? I haven't noticed this kind of change (and we have not been reviewing most patches on the mailing list since a long long time, well before the github switch). I think the change was the movement to github. If we can add sugar-devel mailing list to the github mail destinations, that can be solved. I was mostly concerned about Samuel feeling that everyone is developing they're own version of Sugar. I don't see that or at least I don't see differences with the past. I agree with Samuel; that with the loss of public review of patches participation in development has been confined to those who take the trouble to visit a web site. (The reviews by mail were also stimulating other discussion on list). So on the theory that developers are developing with less review (even though it might be unseen greater review), this leads to the conclusion that Sugar is being developed by these developers on their own. And, actually, I'm fine with that. A smaller group can achieve more if they are able to use these new tools effectively. I have not been effective since that change, but you would have seen that a review counter or tracking? Has there been a measure of review rate? We probably can have sugar-devel as email destination... Though I'm not sure why people wouldn't just watch the modules they are interested in? It seems more flexible. Anyway not opposed to send all modules to the whole mailing list if there is consensus on that. I don't see how watching the modules they are interested in is more flexible, nor whether greater flexibility increases the communication. James, Sam, I see this as a question of taste. At least starters find very odd emails with patch format in pain text. At least one reviewer (me) find very odd copy/pasting the email content to a file in order to give the patch a test. And we had the problem of email-patches being forgotten in the flow of threads. That is fixed, with zero patches in queue. As Daniel said, you can receive email notifications from GitHub by watching repositories. Please don't configure github to send links to the patches; they have to be the patches themselves. They should also have a from address that matches the originator. What used to happen was easy. Get a mail with the patch. Scroll it down while reviewing it. When the cognitive dissonance hits a threshold, hit the reply button and begin a comment. Press send. Mail is a store and forward architecture. I can use mail without having to wait for an internet connection. Github is not so lucky: $ ping -n github.com rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 8 October 2013 00:08, Manuel Quiñones ma...@laptop.org wrote: James, Sam, I see this as a question of taste. Exactly. The sooner people understand that, the sooner we will stop having discussions about the review process over and over :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote: Well everyone seems to be developing their own version of Sugar seems to be more than that. But maybe I'm just reading too much into it. There aren't multiple groups of people or individuals developing sugar on their own. As far as I know all the work that is being done these days is going upstream. Good. I only know of four Sugars. Sugar upstream, Dextrose, what is in OLPC OS, and what is in the Australian builds. There might be more, but I'm not aware of them. I also don't know the difference between each. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, Oct 7, 2013 at 10:10 PM, James Cameron qu...@laptop.org wrote: I agree with Martin on the odd directions Ubuntu is exhibiting; it may be safer to target Debian instead, from which support for Ubuntu will generally follow. (On the other hand, I lack evidence to agree with claims about the stability or direction of Fedora. So few people I know use it.) So few people I know use Windows but that doesn't mean it's no longer prevalent, from what I've seen there's been quite a large swing back to it due to the problems with Ubuntu and most of the upstream developers of a lot of the stack that sugar relies upon now use Fedora as their core development OS because of the issues they see with Ubuntu. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 8 October 2013 00:22, James Cameron qu...@laptop.org wrote: On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote: Well everyone seems to be developing their own version of Sugar seems to be more than that. But maybe I'm just reading too much into it. There aren't multiple groups of people or individuals developing sugar on their own. As far as I know all the work that is being done these days is going upstream. Good. I only know of four Sugars. Sugar upstream, Dextrose, what is in OLPC OS, and what is in the Australian builds. There might be more, but I'm not aware of them. I also don't know the difference between each. Australia builds have apparently a few non-yet-upstreamed patches. Both Gonzalo and Walter are very much involved in upstream work, I'm absolutely confident they will upstream as soon as it make sense. OLPC OS is pretty much all upstream, as far as I know. Dextrose. I know they accumulated non-upstream patches in the past. We landed a couple of features coming from there before the freeze. I'm not sure what is going on these days, which is why I wanted to know more from David about the porting they are doing. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
This actually is kind of what I meant (and perhaps should be a separate thread). My understanding is that deployments nowadays are the primary parties funding Sugar development. And the deployments or their contractors sometimes duplicate work, run into debates upstreaming things, and/or may choose to keep some things semi-private to differentiate their products. So apart from major functionality like HTML5 activities, a lot of peripheral development is happening downstream-first. And when we do try to do major cross-group development like the GTK3 port, this has lead to finger-pointing behind the scenes where it is claimed others are not doing what they promised. To the best of my knowledge no single organization currently employs enough developers and/or contractors to keep Sugar development alive. I am not certain what the best approach to take is when this is the case. On Mon, Oct 7, 2013 at 6:22 PM, James Cameron qu...@laptop.org wrote: On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote: Well everyone seems to be developing their own version of Sugar seems to be more than that. But maybe I'm just reading too much into it. There aren't multiple groups of people or individuals developing sugar on their own. As far as I know all the work that is being done these days is going upstream. Good. I only know of four Sugars. Sugar upstream, Dextrose, what is in OLPC OS, and what is in the Australian builds. There might be more, but I'm not aware of them. I also don't know the difference between each. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
My 2 cents: Since the switch to github, we've have a much better turn-around on reviews and we've attacked new reviewers. I think those data speak for themselves. As Daniel said, we welcome help further shaping the process. regards. -walter On Mon, Oct 7, 2013 at 6:08 PM, Manuel Quiñones ma...@laptop.org wrote: 2013/10/7 James Cameron qu...@laptop.org: Daniel Narvaez wrote: Gonzalo Odiard wrote: Daniel wrote: Gonzalo Odiard wrote: Samuel Wrote: In general one of my frustrations lately is that now that we no longer publicly review patches on this mailing list, everyone seems to be developing their own version of Sugar. Can you elaborate on this one? I haven't noticed this kind of change (and we have not been reviewing most patches on the mailing list since a long long time, well before the github switch). I think the change was the movement to github. If we can add sugar-devel mailing list to the github mail destinations, that can be solved. I was mostly concerned about Samuel feeling that everyone is developing they're own version of Sugar. I don't see that or at least I don't see differences with the past. I agree with Samuel; that with the loss of public review of patches participation in development has been confined to those who take the trouble to visit a web site. (The reviews by mail were also stimulating other discussion on list). So on the theory that developers are developing with less review (even though it might be unseen greater review), this leads to the conclusion that Sugar is being developed by these developers on their own. And, actually, I'm fine with that. A smaller group can achieve more if they are able to use these new tools effectively. I have not been effective since that change, but you would have seen that a review counter or tracking? Has there been a measure of review rate? We probably can have sugar-devel as email destination... Though I'm not sure why people wouldn't just watch the modules they are interested in? It seems more flexible. Anyway not opposed to send all modules to the whole mailing list if there is consensus on that. I don't see how watching the modules they are interested in is more flexible, nor whether greater flexibility increases the communication. James, Sam, I see this as a question of taste. At least starters find very odd emails with patch format in pain text. At least one reviewer (me) find very odd copy/pasting the email content to a file in order to give the patch a test. And we had the problem of email-patches being forgotten in the flow of threads. That is fixed, with zero patches in queue. As Daniel said, you can receive email notifications from GitHub by watching repositories. Please don't configure github to send links to the patches; they have to be the patches themselves. They should also have a from address that matches the originator. What used to happen was easy. Get a mail with the patch. Scroll it down while reviewing it. When the cognitive dissonance hits a threshold, hit the reply button and begin a comment. Press send. Mail is a store and forward architecture. I can use mail without having to wait for an internet connection. Github is not so lucky: $ ping -n github.com rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 8 October 2013 01:07, Samuel Greenfeld greenf...@laptop.org wrote: This actually is kind of what I meant (and perhaps should be a separate thread). To simplify things I will only answer about the 0.100 release cycle. Things have changed a lot anyway and it's probably not worth focusing on the past. My understanding is that deployments nowadays are the primary parties funding Sugar development. And the deployments or their contractors sometimes duplicate work, run into debates upstreaming things, and/or may choose to keep some things semi-private to differentiate their products. There has been debate only about one set of patches which was too big and complicated to review. Someone took care of splitting it up in the end though and it landed. I'm not aware of duplicate work. I'm not aware of semi-private things used to differentiate products. So apart from major functionality like HTML5 activities, a lot of peripheral development is happening downstream-first. And when we do try to do major cross-group development like the GTK3 port, this has lead to finger-pointing behind the scenes where it is claimed others are not doing what they promised. I don't think a lot of development is happening downstream. I have to admit I don't have much visibility about Dextrose/Activity Central though. I think it's fine for some development to land downstream first, as long as it is discussed openly from the beginning. It's often a good way to try things out... To the best of my knowledge no single organization currently employs enough developers and/or contractors to keep Sugar development alive. I am not certain what the best approach to take is when this is the case. I'm more concerned that even summing up the resources, there might not be enough to keep development alive. It really worried me that very little testing, bug triaging and bug fixing is happening for 0.100. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, Oct 7, 2013 at 6:00 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 7 October 2013 23:39, James Cameron qu...@laptop.org wrote: I agree with Samuel; that with the loss of public review of patches participation in development has been confined to those who take the trouble to visit a web site. (The reviews by mail were also stimulating other discussion on list). So on the theory that developers are developing with less review (even though it might be unseen greater review), this leads to the conclusion that Sugar is being developed by these developers on their own. Well everyone seems to be developing their own version of Sugar seems to be more than that. But maybe I'm just reading too much into it. I am only aware of one group developing their own version of Sugar: Activity Central. There is the Sugar Network project as well, but that is more about glue around Sugar. Gonzalo and I are working with Sugar upstream in Australia (although we are ahead of master in a few places as Sugar 100 has been in freeze). There aren't multiple groups of people or individuals developing sugar on their own. As far as I know all the work that is being done these days is going upstream. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, Oct 7, 2013 at 7:45 PM, Ruben Rodríguez ru...@activitycentral.com wrote: Also, there are some bits of code in both Sugar and the activities that assume to be running on Fedora, or even on an XO, and those need cleaning. Be nice to know about these so we can fix them. thx -- Rubén Rodríguez Activity Central: http://activitycentral.com Facebook: https://activitycentral.com/facebook Google+: https://activitycentral.com/googleplus Twitter: https://activitycentral.com/twitter ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Tue, Oct 08, 2013 at 02:00:06AM +0200, Ruben Rodríguez wrote: 2013/10/8 Walter Bender walter.ben...@gmail.com: Be nice to know about these so we can fix them. Sure thing! We just finished with the first leg of the project and the resultant image is getting tested now, so soon I'll start sending patches. There are usually small things, like scripts written in bash (ubuntu uses dash), checking for distro specific files or paths, and the like. I agree, the bash vs dash issue is a small thing, it may be simpler to add bash as a dependency for Sugar. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On Mon, 2013-10-07 at 19:48 -0400, Walter Bender wrote: On Mon, Oct 7, 2013 at 7:45 PM, Ruben Rodríguez ru...@activitycentral.com wrote: Also, there are some bits of code in both Sugar and the activities that assume to be running on Fedora, or even on an XO, and those need cleaning. Be nice to know about these so we can fix them. You can start by looking for olpc specific paths that are hard-coded in places, here is a starting point: https://github.com/sugarlabs/sugar/blob/master/extensions/cpsection/power/model.py https://github.com/sugarlabs/sugar/blob/master/extensions/cpsection/aboutcomputer/model.py https://github.com/sugarlabs/sugar/blob/master/src/jarabe/controlpanel/gui.py Jerry thx -- Rubén Rodríguez Activity Central: http://activitycentral.com Facebook: https://activitycentral.com/facebook Google+: https://activitycentral.com/googleplus Twitter: https://activitycentral.com/twitter ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
