Re: [IAEP] [Sugar-devel] triage meeting
Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.org around for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
I tried to do a migration using trac2github. Here is what it looks like https://github.com/dnarvaez/test/issues/258 It's missing the reporter and it's not filtering by component but these should be easy to add (it's php sigh, but still...). On 19 April 2014 01:03, Daniel Narvaez dwnarv...@gmail.com wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.org around for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
By the way, if we decide to do it I think we should do it *before* the meeting, so that we triage using github already and we don't risk to lose information (or to have a really hard time fixing the script to preserve it). On 19 April 2014 02:03, Daniel Narvaez dwnarv...@gmail.com wrote: I tried to do a migration using trac2github. Here is what it looks like https://github.com/dnarvaez/test/issues/258 It's missing the reporter and it's not filtering by component but these should be easy to add (it's php sigh, but still...). On 19 April 2014 01:03, Daniel Narvaez dwnarv...@gmail.com wrote: Something is probably worth bringing up (it has been discussed a couple of times in irc) is the possibility to migrate to github issues. Maintaining trac is becoming a bit of a burden, especially because of spam prevention. Someone (Bernie?) suggested we could keep bugs.sugarlabs.orgaround for a while but in read-only mode, rather than migrating. Interested in people thoughts, I have not fully considered the migration issue to be honest. On 9 April 2014 14:10, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Yes! I agree. On Thursday, 10 April 2014, Walter Bender walter.ben...@gmail.com wrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:; wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:; wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Software for children learning -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. IMO it's really really important to aggressively close stuff we are not realistically going to fix soon. Otherwise either we waste more time triaging than fixing or we don't triage enough and the bug tracker becomes useless. Just my two cents. We could also keep low for now and see if it really grows too much to be worth retriaging over time. In my experience it's always does but it would be nice to be proven wrong. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a w -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Yes, things we *want* to do are normal priority, my issue is with things that would be nice to do :) Terminology aside, I'm not saying it's bad, just expensive and IMO lower priority then a lot of other awesome things we could do... But if there are people interested in keeping records, all the power to them! On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: I disagree. While is true manage the tickets have cost, is good have a record of things we want to do, even when we don't have the resources today to do it. More in the context of a project where we have volunteers some times more, some times less. Just my two cents ...of pesos :) Gonzalo On Thu, Apr 10, 2014 at 9:27 AM, Daniel Narvaez dwnarv...@gmail.comwrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. IMO it's really really important to aggressively close stuff we are not realistically going to fix soon. Otherwise either we waste more time triaging than fixing or we don't triage enough and the bug tracker becomes useless. Just my two cents. We could also keep low for now and see if it really grows too much to be worth retriaging over time. In my experience it's always does but it would be nice to be proven wrong. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: Well, maybe call iy normal or low instead of minor, but we need a way to separate the tickets we _need_ fix, the tickets we _want_ fix, and the tickets _would_be_nice_ fix. We have almost 250 tickets, if we can solve 50 tickets in these 2 months, is important know what are the best candidates. Gonzalo On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is probably going to be a bit controversial, but I think if something is worth marking minor then it's probably not worth tracking. We will never get to fix the minor but we will waste time triaging and retriaging them. On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: +1 to check if are enhancements or defects. About priorities, we can make something like: blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender walter.ben...@gmail.comwrote: On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. I think we have too many categories for priorities: IMHO, either it is a blocker or it is not. -walter On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. -- Gonzalo Odiard SugarLabs - Software for children learning -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On 10 April 2014 21:18, James Cameron qu...@laptop.org wrote: On Thu, Apr 10, 2014 at 01:27:09PM +0100, Daniel Narvaez wrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. I agree, if there's nobody going to work on a ticket, then close it wontfix. The bug tracking system is useful as a list of non-features. Not what I said. And not even funny. Also, it is common in triage to not process already triaged would be nice tickets, so you shouldn't be wasting triage time on them over and over. If you are, fix your triage process. And how do you avoid the issues getting obsolete (no more relevant, already fixed etc) if not by re-triaging them? That approach has been certainly common in sugar triage until recently. The result was that we couldn't really point any new contributor to the bug tracker because most of the bugs was obsolete. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On 10 April 2014 22:08, Daniel Narvaez dwnarv...@gmail.com wrote: On 10 April 2014 21:18, James Cameron qu...@laptop.org wrote: On Thu, Apr 10, 2014 at 01:27:09PM +0100, Daniel Narvaez wrote: What I'm saying is that the would be nice to fix will never be fixed, they will keep accumulating and we will waste triage time on them over and over. Better to just wontfix them, people can always send patches if they care. Plus we tell them clearly it's up to them to do something if they need them fixed. I agree, if there's nobody going to work on a ticket, then close it wontfix. The bug tracking system is useful as a list of non-features. Not what I said. And not even funny. My sarcasm detector was inaccurate here. Further explanation in irc, which I agree with. 21:30 Quozl` dnarvaez_: the existence of a ticket is a report of feature mismatch between human and software. wontfix is a policy decision of the project. policy can be set by resource constraint. it's fine, close 'em. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, On Wednesday, 9 April 2014, Walter Bender walter.ben...@gmail.com wrote: We plan to hold a triage meeting to clean up bugs.sugarlabs.org on Wednesday, 23 April, beginning at 9AM EST (14 UTC). We will be on irc.freenode.net #sugar-meeting all day. Please join the fun. -- Tenemos la intención de celebrar una reunión de triage para limpiar bugs.sugarlabs.org el miércoles 23 de abril a partir de las 9 a.m. EST (14 UTC). Estaremos en irc.freenode.net #sugar-meeting todo el día. Por favor, únase a la diversión. regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:_e(%7B%7D,'cvml','dwnarv...@gmail.com'); wrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:_e(%7B%7D,'cvml','dwnarv...@gmail.com'); wrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:_e(%7B%7D,'cvml','godi...@sugarlabs.org'); wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.orgjavascript:_e(%7B%7D,'cvml','godi...@sugarlabs.org'); wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] triage meeting
Finally, something I think is important is to set enhancement vs defect. It doesn't take much effort and it's very useful when we are feature frozen. On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.com wrote: Something else to consider is what to do with priorities. It might make sense to set one when confirming bugs, it's hard to get right without spending a lot of time really but maybe helpful for contributors even if not very accurate. On Thursday, 10 April 2014, Daniel Narvaez dwnarv...@gmail.comjavascript:_e(%7B%7D,'cvml','dwnarv...@gmail.com'); wrote: On Thursday, 10 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On Wednesday, 9 April 2014, Gonzalo Odiard godi...@sugarlabs.org wrote: On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote: This is an interesting blog post with a paragraph about GNOME triaging http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ Interestingly it's pretty much exactly the same approach I followed with the triaging I had done with 0.100. It would be good to have a simple set of rule like that written down before the meeting. I think the way we triage has a huge impact on lowering contribution barriers, +1 We need at least verify all the Unconfirmed tickets. We can start now, don't need wait until the triage meeting. I assume, if the bug is confirmed, we should set: Milestone = 0.102 Status = New I wonder about Milestone. It seems like it would only be useful if we assign different milestones to tickets and I'm not sure we can do that without being able to allocate resources to fix them. It's also a time consuming task. True. or close them if are not longer present. Would be good if we can reset all the priorities to Unassigned, in all the tickets with module=Sugar,the field content does not have any sense right now. Do we want to use the field? Otherwise maybe there is a way to just get rid of it. Just to mark they have been triaged, and based in the querys used in bugs.sugarlabs.org home. Do you propose doing in another way? The home queries uses status == unconfirmed for untriaged. The tickets I set status = new (not that many left) have been confirmed. I had reset everything to unconfirmed before starting to triage. -- Daniel Narvaez -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar 0.101.0 (unstable)
Excellent, thanks! On Sunday, 8 December 2013, Peter Robinson wrote: this is the first development release of the cycle that will bring us to 0.102. Highlights: * Allow to limit the number of open activities. * More informations about hardware and software in control panel. * Allow to hide the Register menu. * Add support for 5 GHz frequency channels. * A lot of bugfixes. Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.101.1.tar.xz These are now built for Fedora 21/rawhide. Peter -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar 0.101.0 (unstable)
Hello, this is the first development release of the cycle that will bring us to 0 .102. Highlights: * Allow to limit the number of open activities. * More informations about hardware and software in control panel. * Allow to hide the Register menu. * Add support for 5 GHz frequency channels. * A lot of bugfixes. Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.101.1.tar.xz A lot of people contributed to this release. Thanks to everyone! -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] Election Details for 2013-2014
I have not received your first email at all and this one went to my gmail spam. I don't know if this happened to anyone else but thought it was worth mentioning given the email importance. On Tuesday, 3 December 2013, Luke Faraone wrote: On Mon, Dec 02, 2013 at 10:43:43PM -0500, Luke Faraone wrote: If you or somebody you know should be on the ballot, make sure to publish an announcement of candidacy to IAEP, and put your name on the list[2] before December 7. This should have read December 15. Thanks, Luke Faraone Membership and Elections Committee Sugar Labs Cheers, Luke -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Education freedom day
http://pockey.dao2.com/2013/11/education-freedom-day-celebrations-18-january-2014/ Sad that Sugar is not even mentioned. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Helping with 0.102
Hello, I've been doing a lot of bug triaging but we still have 192 untriaged tickets, hopefully I'll get to the bottom of the list at some point. Though the tickets which have been triaged are hopefully all current, actionable and somewhat prioritized. Or at least that's what I tried to ensure. So if you want to contribute to 0.102, just go to bugs.sugarlabs.org, click on Defects or Enhancements and choose any of them. If you need help understanding the issue or figuring out how to solve it, feel free to post on the list or ping me in irc. I'm happy to mentor. For enhancements I suggest to discuss, irc or list, before getting too much into the implementation, especially if UI is involved. That will ensure we have a consensus about the feature and the details of its implementation. If you lack energy, join the IRC channel and I'm sure GCI will inspire you. We are doing great progress and it's being a lot of fun. I'm mostly giving you chance to tackle some of the issues before the students fix them all :) -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] Fwd: [Sugar-devel] Sugar Labs Roadmap. [SD 61; 79]
-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Bounties
I wonder if we should try to use bountysource.com to fund a few things we consider strategic for Sugar Labs. Just an idea. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Bounties
Yes, certainly, as seen in the various threads we are still figuring out a strategy. I brought this up now because the issue of how to resource work has been coming up a lot in these discussions (and because I just learned about this service). On Friday, 8 November 2013, Walter Bender wrote: First, we need to decide what are those strategic things. -walter On Fri, Nov 8, 2013 at 3:32 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: I wonder if we should try to use bountysource.com to fund a few things we consider strategic for Sugar Labs. Just an idea. -- Daniel Narvaez ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Re library versions, that reminds of a point I should have put in my list... I think now that the gobject introspection migration is over upstream can become more conservative about library versions. That should help both distributors and developers. We are already going in that direction really. If we add Webkit1 compatibility as discussed, I think 0.102 might have pretty much the same dependencies of 0.98. The only exception is libxkb if I remember correctly, for which introspection was really broken. On Thursday, 7 November 2013, David Farning wrote: I agree :) Right now, we are sitting back and seeing what roll OLPC-Australia is going to play in the ecosystem. The One Education distribution out of Australia is a combination of Dextrose, Sugar .100 and some custom patches. My semi-informed guess is that Walter and Rangan ( https://www.laptop.org.au/about ) are going to position One Education as the successor to OLPC-OS. I hope that we will learn more at about their plans at basecamp. ( http://olpcbasecamp.blogspot.com/ ) This would take care or the leading edge on Fedora. On the Ubuntu side we have a bit of a challenge balancing bleeding edge and stability. Sugar and Fedora tend to run a bit ahead of Debian and Ubuntu in library versions. It take a significant amount of effort to backport the necessary libraries to Ubuntu LTS. For this release we agreed that the proper balance of innovation and stability was Sugar .98 on Ubuntu 12.04. The next decision point will be which version of Sugar to use for the 14.04 release due in the second quarter of 2014. On Wed, Nov 6, 2013 at 8:05 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Cool stuff. As for Fedora it would be great to have builds with the latest sugar (stable and unstable) releases. I'm not saying to ship those to deployments of course, but they would help upstream development, marketing and testing... And they would help AC to make the transition to the next sugar release smoother. On 7 November 2013 02:05, David Farning dfarn...@activitycentral.comjavascript:; wrote: Please see the link at the bottom left of http://dextrose.ac/platform/ for the Sugar on Ubuntu images which Activity Central and Plan Ceibal are jointly developing. For stability it is based on Ubuntu 12.04 and Sugar .98. The testing is done on classmate to meet Plan Ceibal's specifications. I should work equally well on any machine that boots Ubuntu. It is currently is small scale testing by a couple hundred teachers. When the image meets Ceibal's quality standards the pilot will scale to approximately 10,000 units for wider testing. For more information, I have CC Anish Mangal, the project owner (agile speak) and Ruben Rodriguez the lead developer. Ruben has the strongest back ground on the technical issues involved in the port. Anish has the deepest understanding of timelines and objectives. On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.orgjavascript:; wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com -- Daniel Narvaez -- David Farning Activity Central: http://www.activitycentral.com -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Yes with dependencies I also meant the version of them (for API incompatible versions at least). I'm all for getting concrete :) On Thursday, 7 November 2013, David Farning wrote: On Thu, Nov 7, 2013 at 12:30 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Re library versions, that reminds of a point I should have put in my list... I think now that the gobject introspection migration is over upstream can become more conservative about library versions. That should help both distributors and developers. We are already going in that direction really. If we add Webkit1 compatibility as discussed, I think 0.102 might have pretty much the same dependencies of 0.98. The only exception is libxkb if I remember correctly, for which introspection was really broken. In addition to dependencies there can be issues with versions of dependencies. Within the next couple of week we should see these fixes flow upstream. So we can start talking about concrete issues and examples rather than abstract notions. I think that will help clarify the discussion. AC's challenge was to quietly get a proof of concept in place which adds value to deployments before suggesting making changes to upstream. Now, AC has to clean up and abstract the proof of concept work to prepare it for acceptance upstream. On Thursday, 7 November 2013, David Farning wrote: I agree :) Right now, we are sitting back and seeing what roll OLPC-Australia is going to play in the ecosystem. The One Education distribution out of Australia is a combination of Dextrose, Sugar .100 and some custom patches. My semi-informed guess is that Walter and Rangan ( https://www.laptop.org.au/about ) are going to position One Education as the successor to OLPC-OS. I hope that we will learn more at about their plans at basecamp. ( http://olpcbasecamp.blogspot.com/ ) This would take care or the leading edge on Fedora. On the Ubuntu side we have a bit of a challenge balancing bleeding edge and stability. Sugar and Fedora tend to run a bit ahead of Debian and Ubuntu in library versions. It take a significant amount of effort to backport the necessary libraries to Ubuntu LTS. For this release we agreed that the proper balance of innovation and stability was Sugar .98 on Ubuntu 12.04. The next decision point will be which version of Sugar to use for the 14.04 release due in the second quarter of 2014. On Wed, Nov 6, 2013 at 8:05 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Cool stuff. As for Fedora it would be great to have builds with the latest sugar (stable and unstable) releases. I'm not saying to ship those to deployments of course, but they would help upstream development, marketing and testing... And they would help AC to make the transition to the next sugar release smoother. On 7 November 2013 02:05, David Farning dfarn...@activitycentral.com wrote: Please see the link at the bottom left of http://dextrose.ac/platform/ for the Sugar on Ubuntu images which Activity Central and Plan Ceibal are jointly developing. For stability it is based on Ubuntu 12.04 and Sugar .98. The testing is done on classmate to meet Plan Ceibal's specifications. I should work equally well on any machine that boots Ubuntu. It is currently is small scale testing by a couple hundred teachers. When the image meets Ceibal's quality standards the pilot will scale to approximately 10,000 units for wider testing. For more information, I have CC Anish Mangal, the project owner (agile speak) and Ruben Rodriguez the lead developer. Ruben has the strongest back ground on the technical issues involved in the port. Anish has the deepest understanding of timelines and objectives. On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Tech roadmap
Hello, I think Sugar Labs needs to express a clear, realistic technology roadmap. For example, we have been talking a lot about Sugar on Android, mixing a lot of different things under that name. We need to clarify what that really is. Here are my thoughts, inspired by the oversight board meeting thread. * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. * Work with deployments to see if there are complete hardware solutions (Chromebooks for example) they could use. In the case of locked devices they might have the where-with-all to load custom software. * Migrate from X to Wayland or support it in parallel (depending on the performance of non accellerated Wayland). GNOME is doing most of the work, but we will need the rework the window management bits. This will allow us to run on Android drivers with libhybris, which should help with hardware support. As you might have noticed there is no Sugar on Android, other than for drivers support and web activities running in a web browser. I don't think going beyhond those gives us any real advantage. Just my $0.02 -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On 6 November 2013 16:12, Gonzalo Odiard gonz...@laptop.org wrote: * Wait and see what happens with the XO. Support existing deployments by producing images with the most recent Sugar release. Stick to a Fedora 18 base system, the work to upgrade is highly non trivial. Provide custom rpms for the sugar modules and a few dependencies, most importantly Webkit, which is required by web activities. In the short term, we don't need backport Webkit2 to F18. Please elaborate :) I think developing web activities on two very different platforms (WebKit1 and WebKit2) is a bad idea, it will involve more work (and pain) then doing some backporting. In the long term, we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21. Yes, ideally. I just don't see this happening in the short time and I'm worried it might not happen at all, given the kind of work that seems to be involved. It would be awesome to be proven wrong... Until that happens though I think we need to be able to get the latest sugar (and it's dependencies) on a XO. * Ensure web activities run well in web browsers. This will cover Android and other non-Linux systems. * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one or two ARM boards (Beagle board black and Cubox-i seems to be the best we could pick at the moment). Talk to the manufacturers to get publicity on the images we produce and devices for the developers. Maybe not only ARM hardware. At least in South America, many places are using Classmates in educative projects. I know talks between OLPC and Intel were difficult in the past, but is a different world now. Yes! I think it would be good to research Intel hardware. After all they are using this wonderful secure boot stuff (sigh) instead of locking the OS, which would make things much easier... ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
On 6 November 2013 16:45, Gonzalo Odiard gonz...@laptop.org wrote: In the short term, we don't need backport Webkit2 to F18. Please elaborate :) I think developing web activities on two very different platforms (WebKit1 and WebKit2) is a bad idea, it will involve more work (and pain) then doing some backporting. Well, with a little patch in our F18 rpm, I have all the web activities working ok in webkit1. A important missing feature is the web inspector, but they work ok. We never solved the document domain issue right (if I remember correctly you failed to get a in-activity web server running)? Current web activities are super simple but as they become more complex I think we will run into issues, domain being just one example. I'd rather not have to figure out WebKit1 *and* WebKit2 solutions every time that happens. I was looking at compile the webkit rpm from F19 in F18, but had many dependencies. I didn't explore other alternatives. Yeah, we might need to rebuild a few other deps. As soon as I have a bit of time I plan to look into doing these rebuilds in an automated way using COPR. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Gstreamer 0.10 is part of what I'm calling gtk2 toolkit, it's not completely accurate but we have been using than terminology. So it seems we are going to run into the issue of gtk2 toolkit pieces disappearing earlier then I expected. I think you can move to gst 1.0 only if you already ported to gtk3. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Tech roadmap
Did you run into any specific issue? On Wednesday, 6 November 2013, Walter Bender wrote: On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard gonz...@laptop.orgjavascript:; wrote: Clock, Speak, and part of Memorize use gstreamer just to do text to speech. I would like to have tts provided by Sugar as a service, probably using dbus and a api in sugar-toolkit-gtk3. That would simplify these activities and solve other problems we have, like by example the keep the language names translated and updated in every place. I've had a few false starts trying to port Measure to GST 1.0. Once I get that working, Turtle Art will follow (that is why I still haven't released the GTK 3 version of Turtle Art). -walter Gonzalo On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: I forgot a note about toolkits * The gtk2 toolkit is deprecated and frozen but it will be supported as long as possible (at some point I guess some dependencies might start disappearing from distributions, making that problematic). The gtk3 toolkit is supported, backward API compatibility is guaranteed, it's not going to be deprecated in the foreseable future. The web toolkit is experimental, we provide no API guarantee yet, when it's mature it will be the preferred way to write activities (because of cross platform compatibility). The other one to add to this list is gstreamer. At the moment we have some support for gstreamer 1.0 and some (mostly gtk2) Activities still using gstreamer 0.10. The 0.10 release will be disappearing sooner rather than later (I wouldn't be surprised if this happened in F-21/F-22 time frame). I would love to see us be able to remove the dependency on two gst stacks, at the moment at least Clock, Speak, Record and Memorise need to be converted from gstreamer-python / gst 0.10 to gst 1.0 with Introspection support, whether this requires migration to gtk3 at the same time is unknown to me. Peter ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Tech roadmap
Cool stuff. As for Fedora it would be great to have builds with the latest sugar (stable and unstable) releases. I'm not saying to ship those to deployments of course, but they would help upstream development, marketing and testing... And they would help AC to make the transition to the next sugar release smoother. On 7 November 2013 02:05, David Farning dfarn...@activitycentral.comwrote: Please see the link at the bottom left of http://dextrose.ac/platform/ for the Sugar on Ubuntu images which Activity Central and Plan Ceibal are jointly developing. For stability it is based on Ubuntu 12.04 and Sugar .98. The testing is done on classmate to meet Plan Ceibal's specifications. I should work equally well on any machine that boots Ubuntu. It is currently is small scale testing by a couple hundred teachers. When the image meets Ceibal's quality standards the pilot will scale to approximately 10,000 units for wider testing. For more information, I have CC Anish Mangal, the project owner (agile speak) and Ruben Rodriguez the lead developer. Ruben has the strongest back ground on the technical issues involved in the port. Anish has the deepest understanding of timelines and objectives. On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 6 November 2013 16:20, Manuel Quiñones ma...@laptop.org wrote: Classmates are basically just x86 netbooks, I've not tried it as I don't have HW but I don't see any reason they shouldn't work OOTB. Yep. Sugar is running in classmates out of the box. In Uruguay for example. You mean people are using them in Uruguay deployments? Which distro? ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Activity Central: http://www.activitycentral.com -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Well, my impression is that at the moment we have a well defined
educational vision and a pretty solid UX design based on it. What we lack
is an hardware+software platform to run it on. So I don't think trying to
find a solution for that is getting bogged down, all the contrary.
On Tuesday, 5 November 2013, Caryl Bigenho wrote:
Hi…
Last year at SCaLE George Hunt helped me get Sugar running on my RPi.
Because our booth was so busy, it took parts of both Saturday and Sunday to
get it going. I then tried it when I got home and found that it was prone
to stalls. Of course, this was back in late February and there may have
been improvements since then. If so, please let me know where to find the
download and instructions for installing.
I would like to suggest we keep the idea of Sugar on the RPi in mind, but
perhaps in a smaller, reduced size with only a few carefully selected
Activities. Perhaps it could be called A Taste Of Sugar.
Remember, the whole idea behind the RPi is to get young people involved in
really learning about computers and computing and to do creative things
with them. With this in mind, some of the Activities that could be part
of a small version of Sugar might include Turtle Blocks for robotics, a
small version of Tam Tam for experimenting with creating musical sounds and
actually composing with loops (I realize even a tiny version of Tam Tam
would be a huge undertaking, but very worthwhile), Pippy for learning
Python, etc.
As we discuss where our group(s) should focus in the future, let's try not
to get to bogged down in discussions of hardware platforms and software
solutions. First and foremost we might want to consider the educational
experience we want to make available to students. Hopefully, it will be
something that fosters creativity, collaboration, and problem solving while
making projects of all kinds imaginable.
Caryl
Date: Tue, 5 Nov 2013 13:46:31 +1100
From: qu...@laptop.org javascript:_e({}, 'cvml', 'qu...@laptop.org');
To: satelli...@gmail.com javascript:_e({}, 'cvml',
'satelli...@gmail.com');
CC: dwnarv...@gmail.com javascript:_e({}, 'cvml',
'dwnarv...@gmail.com');; market...@lists.sugarlabs.orgjavascript:_e({},
'cvml', 'market...@lists.sugarlabs.org');;
sugar-de...@lists.sugarlabs.org javascript:_e({}, 'cvml',
'sugar-de...@lists.sugarlabs.org');;
iaep@lists.sugarlabs.orgjavascript:_e({}, 'cvml',
'iaep@lists.sugarlabs.org');;
olpc-...@lists.laptop.org javascript:_e({}, 'cvml',
'olpc-...@lists.laptop.org');
Subject: Re: [IAEP] [Sugar-devel] [Marketing] [Sur] Sugar oversight
board meeting
On Mon, Nov 04, 2013 at 04:40:51PM -0800, Thomas Gilliard wrote:
On 11/4/2013 4:17 PM, Daniel Narvaez wrote:
On 4 November 2013 23:05, Peter Robinson
pbrobin...@gmail.comjavascript:_e({}, 'cvml', 'pbrobin...@gmail.com');
wrote:
Sugar on Android or the Raspberry Pi might have an interesting
marketing effect but the result would be truly terrible as it would be
essentially unusable and have a terrible experience.
Can you elaborate on why you think it would be a terrible experience
on the
Raspberry Pi? I never tested it there, I was just hoping it could be a
nice
target...
Look at these older tests of sugar on the RPi:
http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi
This part of the Advanced topics wiki page on the sugarlabs wiki:
http://wiki.sugarlabs.org/go/Sugar_Creation_Kit/sck/Advanced_Topics#ARM
Tom Gilliard
I could not find any evidence of user experience testing, or
performance evaluation, in the two links you gave. Did you give the
right ones?
I agree with Peter, I don't think it will perform well, but I don't
know in what way it won't perform well, so I can't guess where effort
would have to be spent to fix it.
(especially in comparison to an XO-1)
--
James Cameron
http://quozl.linux.org.au/
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org javascript:_e({}, 'cvml',
'IAEP@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/iaep
--
Daniel Narvaez
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Sorry for the top posting, quoting on gmail on iPhone is a pain. * I'm glad that you see some runway for the XO and I really hope you are right, it would be awesome. I think even just the uncertainity is a big issue for upstream development at the moment. Not knowing if anyone is going to build F20 based images for example... * The issue I see with Chromebook is that it's mostly a locked down platform. It has a supported developer mode which is better than nothing but I'm not sure is enough. How many people will feel like going through the hassle and risk to break their working OS? Will deployments be able to work with something like that? It even requires to ctrl-d on every boot... I sort of wish the ARM vendors started to use secure uefi, and that's saying it all :/ On Tuesday, 5 November 2013, Walter Bender wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com javascript:; wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. -- Daniel Narvaez ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/sugar-devel -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Thanks a lot for the feedback Peter. I will check these out. For the record, I was thinking about Sugar on Linux on Raspberry, not Android. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Do you know what's the status of graphics with the BeagleBone Black? On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Is 3D support for the BBB not planned/possible? I know we don't require it at the moment but it would be nice to have in the future (and it *might* speed up things even with the current software...). On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 1:16 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Do you know what's the status of graphics with the BeagleBone Black? Sugar on the BBB should work fine with the modesetting driver OOTB (I've still got some kernel bits to do in Fedora, 3.12 should be much better) as it doesn't need 3D. The i.MX6 devices (WandBard, Utilite, CuBox-i etc) should have accelerated graphics in the F-21 time frame. Peter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 12:17 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.comjavascript:; wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... It's generally not particularly fast and has a number of HW problems, as a look at how cool we are I wouldn't be chosing the RPi to run sugar on Android, even on Linux the experience isn't great. There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). Well Fedora produces SoaS on ARM images that will run on any of the ARM platforms Fedora supports. I would be looking at BeagleBone Black [1] (improvements still needed, should be much better soon), Wandboard [2], Utilite [3] (little brother to the TrimSlice) or the CuBox-i [4]. The last of which has the cheapest model at $45 in a case and will be much faster, we should have OOTB graphics for the last 3 devices (all based on the i.MX6) in Fedora 21 (maybe later in the F-20 cycle) and the experience will be much better for little to no price increase over the RPi. [1] http://beagleboard.org/Products/BeagleBone%20Black [2] http://www.wandboard.org/ [3] http://utilite-computer.com/ [4] http://cubox-i.com/table/ -- Daniel Narvaez -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.comjavascript:; wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com javascript:; wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Yeah, my target here is development and testing, not final users. Basically I'm talking about what Gonzalo has been doing for 0.100. We could automate that work, it just feels a bit wrong to me because it's not using the normal Fedora infrastructure... On Tuesday, 5 November 2013, Walter Bender wrote: On Tue, Nov 5, 2013 at 8:40 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Going a bit off topic, but a pretty major issue I see in our workflow with Fedora is that we don't have a good way to develop unstable Sugar on a stable Fedora. Rawhide is, or at least is perceived as, unstable. And I'm not sure what would be a good way to, for example, produce and distribute 0.100 rpms for Fedora 19. We can setup our custom automated build system and repository of course, but I'm not sure that's a good approach? Part of the problem here is that upstream tends to depend strongly on very recent libraries which are not yet available in the stable fedora, though maybe now that the gi conversion is over we can avoid that. I think it is doable. The more difficult part is getting the Fedora bits to run properly on the XO hardware -- something OLPC had spent lots of time on. So while I think we can make Fedora releases -- and probably should -- they probably won't do much good directly for our major user community. -walter On Tuesday, 5 November 2013, Peter Robinson wrote: On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.comjavascript:; wrote: On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: On 4 November 2013 22:53, Sean DALY sdaly...@gmail.comjavascript:; wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. I may be alone in thinking that there will be some runway left with the XO. But deployments need alternatives regardless. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. I agree. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. We looked at ChromeOS a few years back, but at the time it was too heavy for our hardware. Today, it is a different story. Might be a viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is not a bad starting point. Given that ChromeOS is locked down I don't believe it's viable to ask a School to have to break/hack the HW to get it working OOTB. Having been involved in the OLPC OS side of things I believe you would be much better taking the work done by OLPC with things like olpc-os-builder and the work upstream with Fedora to use it to build out OS images that will work in a similar way across both XOs and other HW be it x86 netbook or cheap ARM devices rather than reinventing the wheel! Peter -- Daniel Narvaez -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar oversight board meeting
Hi Flavio,
I'm not sure what you are flagging as a mistake exactly, there is quite a
bit of confusion around android and html5, it means very different things
to different people. So it would be good if you could clarify.
And I'm not sure what you are proposing. Certainly everyone in this thread
would be glad if the XO development continued as usual, but that's not what
seems to be happening, independently from our will.
I'm seeing a lot of educators vs developers rhetoric lately and I don't
think it's useful. It would be better if we focused on improving the
communication channels. Feedback is not taken in account because it's not
heard, most of the time.
I'm just a volunteer trying to help out, one of the many on this list :)
On Tuesday, 5 November 2013, Flavio Danesse wrote:
My humble opinion (please stick to one):
To put into perspective the opinion, I should remember that besides
developing for sugar since 2009, I am also a teacher in high school, so
I've been inside ceibal classrooms during this time.
From the beginning, I said I saw the fate of sugar linked to the xo, the
one without the other does not seem to make sense. Now, OLPC xo 4 and
manufactures their away strip.
For those who did the port to gtk3 last year, and we have also had to deal
with the problems of arm processors, etc.. . ., We do not easily see how
much time is lost in these strategic decisions while it ignores the
feedback from deployments.
I think this whole issue of android and html5, is a very grave mistake,
probably the last.
But hey, I'm just a teacher, probably the only one in this list.
2013/11/5 Daniel Narvaez dwnarv...@gmail.com javascript:_e({}, 'cvml',
'dwnarv...@gmail.com');
Oh, awesome, COPR seems to be exactly what we need.
On Tuesday, 5 November 2013, Peter Robinson wrote:
On Tue, Nov 5, 2013 at 1:40 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
Going a bit off topic, but a pretty major issue I see in our workflow
with
Fedora is that we don't have a good way to develop unstable Sugar on a
stable Fedora. Rawhide is, or at least is perceived as, unstable. And
I'm
not sure what would be a good way to, for example, produce and
distribute
0.100 rpms for Fedora 19. We can setup our custom automated build
system and
repository of course, but I'm not sure that's a good approach? Part of
the
problem here is that upstream tends to depend strongly on very recent
libraries which are not yet available in the stable fedora, though
maybe now
that the gi conversion is over we can avoid that.
Actually a lot of that will be solved perfectly with COPR (similar in
style to Ubuntu PPA) which is being worked upon at the moment and it
should solve all the problems you see by enabling newer versions to be
built for older releases while maintaining the stable shipped release
in mainline.
Peter
On Tuesday, 5 November 2013, Peter Robinson wrote:
On Tue, Nov 5, 2013 at 2:14 AM, Walter Bender walter.ben...@gmail.com
wrote:
On Mon, Nov 4, 2013 at 7:42 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote:
* It's not clear to me where we are going. The OLPC/Sugar
development
ecosystem seems to be at a crossroads. I am encouraged by the web
activity
work, but don't understand the path of transposing the value
proposition of
Sugar (interface, Journal, collaboration, Activities) to handheld
tactile
devices (tablets to smartphones). PCs (of any size) with keyboards
are
no
longer competitive with tablets for grade-school classroom use.
Perhaps the
XO-4 could still be in the running; there is no clear message from
OLPC.
I'll try to express briefly my feelings about the directions the
project
could take. Note that I might be missing a lot of what is going on
above the
technical level.
* The XO is not a viable hardware platform other than for existing
deployments. OLPC is pretty clearly going in a different direction.
I may be alone in thinking that there will be some runway left with
the XO. But deployments need alternatives regardless.
* Sugar web activities on the top of a full Android loses too much
of
the
Sugar value proposition. It's great to have it in addition to
Sugar-the-OS,
but it's not enough alone.
I agree.
* From the technical point of view there are several ways to get
Sugar-the-OS running on tactile devices. Unfortunately it's not
clear
to me
that any of these devices is open enough to be viable for
deployments
or
ordinary users.
We looked at ChromeOS a few years back, but at the time it was too
heavy for our hardware. Today, it is a different story. Might be a
viable option. Certainly running GNU/Linux/Sugar on a ChromeBook is
not a bad starting point.
Given that ChromeOS is locked down I don't believe it's viable to ask
a School to have
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
I don't have much of a clue about Write but... can you send the activity log? On 4 November 2013 16:14, Peter Robinson pbrobin...@gmail.com wrote: On Fri, Nov 1, 2013 at 12:45 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, we are proud to announce the release of Sugar 0.100.0. A lot is new for both users and developers, see the release notes http://wiki.sugarlabs.org/go/0.100/Notes Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.100.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.100.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.100.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.100.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.100.0.tar.xz Thanks to everyone that contributed with code, translations and testing! These are now in updates-testing in Fedora 20. They're not yet in the Fedora 20 stable channel because they're locked down for Beta but will land in stable shortly after Beta. It would be good to get some wider testing and feedback. The big issue at the moment is Write failing to run and I would love some assistance in debugging and fixing that soon so we can ship it in SoaS 10. The latest Beta RC2 images can be found here: x86 (32 and 64 bit) http://alt.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Live/ ARM http://alt.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Images/armhfp/ Peter -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
That's a segmentation fault I think. It would be good if you could launch
it with sugar-launch -d and post the backtrace., possibly after having
installed debug packages.
On 4 November 2013 21:25, Peter Robinson pbrobin...@gmail.com wrote:
On Mon, Nov 4, 2013 at 8:13 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
I don't have much of a clue about Write but... can you send the activity
log?
It unfortunately only contains a single line:
Terminated by signal 11, pid 14089 data (None, open file 'fdopen',
mode 'w' at 0x2e13540,
dbus.ByteArray('ef47d2e4dc6551ba96f6ceded9023243ea4ee519
', variant_level=1))
On 4 November 2013 16:14, Peter Robinson pbrobin...@gmail.com wrote:
On Fri, Nov 1, 2013 at 12:45 AM, Daniel Narvaez dwnarv...@gmail.com
wrote:
Hello,
we are proud to announce the release of Sugar 0.100.0. A lot is new
for
both
users and developers, see the release notes
http://wiki.sugarlabs.org/go/0.100/Notes
Sources:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.100.0.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.100.0.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.100.0.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.100.1.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.100.0.tar.xz
Thanks to everyone that contributed with code, translations and
testing!
These are now in updates-testing in Fedora 20. They're not yet in the
Fedora 20 stable channel because they're locked down for Beta but will
land in stable shortly after Beta. It would be good to get some wider
testing and feedback. The big issue at the moment is Write failing to
run and I would love some assistance in debugging and fixing that soon
so we can ship it in SoaS 10.
The latest Beta RC2 images can be found here:
x86 (32 and 64 bit)
http://alt.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Live/
ARM
http://alt.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Images/armhfp/
Peter
--
Daniel Narvaez
--
Daniel Narvaez
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
Broken annotation in abiword. Trying to figure out the correct one then
I'll open a bug + patch.
On 4 November 2013 22:40, Peter Robinson pbrobin...@gmail.com wrote:
On Mon, Nov 4, 2013 at 8:30 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
That's a segmentation fault I think. It would be good if you could
launch it
with sugar-launch -d and post the backtrace., possibly after having
installed debug packages.
2Gb of debuginfo later I have the following:
http://paste.fedoraproject.org/51575/38360107/
Thanks,
Peter
On 4 November 2013 21:25, Peter Robinson pbrobin...@gmail.com wrote:
On Mon, Nov 4, 2013 at 8:13 PM, Daniel Narvaez dwnarv...@gmail.com
wrote:
I don't have much of a clue about Write but... can you send the
activity
log?
It unfortunately only contains a single line:
Terminated by signal 11, pid 14089 data (None, open file 'fdopen',
mode 'w' at 0x2e13540,
dbus.ByteArray('ef47d2e4dc6551ba96f6ceded9023243ea4ee519
', variant_level=1))
On 4 November 2013 16:14, Peter Robinson pbrobin...@gmail.com
wrote:
On Fri, Nov 1, 2013 at 12:45 AM, Daniel Narvaez dwnarv...@gmail.com
wrote:
Hello,
we are proud to announce the release of Sugar 0.100.0. A lot is new
for
both
users and developers, see the release notes
http://wiki.sugarlabs.org/go/0.100/Notes
Sources:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.100.0.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.100.0.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.100.0.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.100.1.tar.xz
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.100.0.tar.xz
Thanks to everyone that contributed with code, translations and
testing!
These are now in updates-testing in Fedora 20. They're not yet in the
Fedora 20 stable channel because they're locked down for Beta but
will
land in stable shortly after Beta. It would be good to get some wider
testing and feedback. The big issue at the moment is Write failing to
run and I would love some assistance in debugging and fixing that
soon
so we can ship it in SoaS 10.
The latest Beta RC2 images can be found here:
x86 (32 and 64 bit)
http://alt.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Live/
ARM
http://alt.fedoraproject.org/pub/alt/stage/20-Beta-RC2/Images/armhfp/
Peter
--
Daniel Narvaez
--
Daniel Narvaez
--
Daniel Narvaez
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
On 5 November 2013 00:07, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 4, 2013 at 10:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Broken annotation in abiword. Trying to figure out the correct one then I'll open a bug + patch. Thanks! Let me know when you've got a patch and I'll test it. Here it is http://bugzilla.abisource.com/show_bug.cgi?id=13572 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
:) On 5 November 2013 00:23, Chris Leonard cjlhomeaddr...@gmail.com wrote: I poked my abiword friends, expect the commit shortly. cjl On Mon, Nov 4, 2013 at 6:13 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 5 November 2013 00:07, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 4, 2013 at 10:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Broken annotation in abiword. Trying to figure out the correct one then I'll open a bug + patch. Thanks! Let me know when you've got a patch and I'll test it. Here it is http://bugzilla.abisource.com/show_bug.cgi?id=13572 ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar 0.100.0 (stable)
On 5 November 2013 00:13, Daniel Narvaez dwnarv...@gmail.com wrote: On 5 November 2013 00:07, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 4, 2013 at 10:59 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Broken annotation in abiword. Trying to figure out the correct one then I'll open a bug + patch. Thanks! Let me know when you've got a patch and I'll test it. Here it is http://bugzilla.abisource.com/show_bug.cgi?id=13572 I suspect this was worked around in OLPC rpms btw http://bugzilla.abisource.com/show_bug.cgi?id=13420#c4 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. I'm afraid you are not the only one feeling that way. It's much easier said than done, but we need to figure out where we are going and to communicate it clearly inside the community. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
On 4 November 2013 23:05, Peter Robinson pbrobin...@gmail.com wrote: Sugar on Android or the Raspberry Pi might have an interesting marketing effect but the result would be truly terrible as it would be essentially unusable and have a terrible experience. Can you elaborate on why you think it would be a terrible experience on the Raspberry Pi? I never tested it there, I was just hoping it could be a nice target... There are a number of other ARM devices that sugar runs beautifully on though. It would also be interesting to know more about these devices. With OLPC going the Android way, I wish there was at least one popular enough device on which we could provide a really good experience (with our scarce resources). ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sur] Sugar oversight board meeting
On 4 November 2013 22:53, Sean DALY sdaly...@gmail.com wrote: * It's not clear to me where we are going. The OLPC/Sugar development ecosystem seems to be at a crossroads. I am encouraged by the web activity work, but don't understand the path of transposing the value proposition of Sugar (interface, Journal, collaboration, Activities) to handheld tactile devices (tablets to smartphones). PCs (of any size) with keyboards are no longer competitive with tablets for grade-school classroom use. Perhaps the XO-4 could still be in the running; there is no clear message from OLPC. I'll try to express briefly my feelings about the directions the project could take. Note that I might be missing a lot of what is going on above the technical level. * The XO is not a viable hardware platform other than for existing deployments. OLPC is pretty clearly going in a different direction. * Sugar web activities on the top of a full Android loses too much of the Sugar value proposition. It's great to have it in addition to Sugar-the-OS, but it's not enough alone. * From the technical point of view there are several ways to get Sugar-the-OS running on tactile devices. Unfortunately it's not clear to me that any of these devices is open enough to be viable for deployments or ordinary users. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar 0.100.0 (stable)
Hello, we are proud to announce the release of Sugar 0.100.0. A lot is new for both users and developers, see the release notes http://wiki.sugarlabs.org/go/0.100/Notes Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.100.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.100.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.100.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.100.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.100.0.tar.xz Thanks to everyone that contributed with code, translations and testing! -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Arch Linux XO image and Sugar packages
Hi Christophe, sorry for the delay. I haven't tried your packages yet because being a developer I prefer to work from git master... though it's great to have stable packages for Arch of course! Now that 0.100 is out you should be able to get rid of the python2 sed stuff simplifying the PKGBUILDs a bit. On 14 October 2013 12:37, Christophe Guéret christophe.gue...@dans.knaw.nlwrote: Hello, Nice! I'm maintaining a couple of packages in AUR using the version of the packages shipped in the latest stable release (currently the 13.2.0). Please, let me know if these package do not work for you and if they need to be fixed ;-) Cheers, Christophe On 6 October 2013 01:59, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I recently switched to Arch Linux and I put together a couple of things that others might find useful. * A trivial script to build minimal images for the XO. It builds a kernel from the OLPC git repository and put it together with prebuilt packages from the Arch Linux ARM project. It's enough to setup a wifi connection and install more stuff with pacman. It's XO 1.75 specific at the moment, but it should be easy to make it work on other versions. https://github.com/dnarvaez/archxo I will post a prebuilt image later. * AUR -git packages for the Sugar core and the browse activity. They makes it pretty easy to install the very latest sugar. (I tested them on my laptop, not on the XO yet). All of these are very much a work in progress. I'm posting them mostly because they might be of interest for Arch Linux users. Patches and bug reports both appreciated! -- Daniel Narvaez -- Onderzoeker +31(0)6 14576494 christophe.gue...@dans.knaw.nl *Data Archiving and Networked Services (DANS)* DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op www.dans.knaw.nl voor meer informatie en contactgegevens. DANS is een instituut van KNAW en NWO. *Let's build a World Wide Semantic Web!* http://worldwidesemanticweb.org/ *e-Humanities Group (KNAW)* http://ehumanities.nl/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Arch Linux XO image and Sugar packages
On Wednesday, 9 October 2013, James Cameron wrote: On Tue, Oct 08, 2013 at 09:32:34PM -0500, Sebastian Silva wrote: dir u:\ clears the screen and shows some garbled text. On my laptop the usb drive mounts fine. Strange, no ? Looking into it further, it may relate to how Daniel advises you to effectively destroy the device partition table by making the filesystem on /dev/sdb rather than the usual methods. The result may depend on what is already on the USB drive, and so is less predictable Can you explain why the result depends on what is already on the drive? Thanks -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Arch Linux XO image and Sugar packages
On 7 October 2013 05:14, Sebastian Silva sebast...@fuentelibre.org wrote: El 05/10/13 18:59, Daniel Narvaez escribió: * AUR -git packages for the Sugar core and the browse activity. They makes it pretty easy to install the very latest sugar. (I tested them on my laptop, not on the XO yet). Nice to hear, I've had a 0.96 on my laptop since I switched to Arch based distro and it was not much use. I tried your packages and my test reports sugar-git installed jarabe in python3.3's site-packages instead of python2.7, so it won't start Good catch, I probably had no python3 installed when I tested these, so I had not seen the issue. I just opened a pull request that should solve it https://github.com/sugarlabs/sugar/pull/104 Thanks! ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Arch Linux XO image and Sugar packages
Hello, I setup a buildbot instance to build the packages daily, using the XO as a build slave for arm http://sugarlabs.org:8011/waterfall https://github.com/dnarvaez/archbot You can pull them by adding this to your /etc/pacman.conf [sugar] SigLevel = Never Server = http://sugarlabs.org/~dnarvaez/archsugar/$arch I tested them on my laptop and on the XO. Though Arch Linux Arm supports a lot of devices, including the Raspberry PI http://archlinuxarm.org/platforms If you have any of these please give it a try, I'd be happy to try to fix stuff up if it doesn't work for some reason. (I have armv7 packages but not armv6 and armv5 yet, as you can see from the buildbot, hopefully I will figure out those soon). ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Arch Linux XO image and Sugar packages
On 6 October 2013 01:59, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I recently switched to Arch Linux and I put together a couple of things that others might find useful. * A trivial script to build minimal images for the XO. It builds a kernel from the OLPC git repository and put it together with prebuilt packages from the Arch Linux ARM project. It's enough to setup a wifi connection and install more stuff with pacman. It's XO 1.75 specific at the moment, but it should be easy to make it work on other versions. https://github.com/dnarvaez/archxo I will post a prebuilt image later. Here it is http://sugarlabs.org/~dnarvaez/archxo/archxo-1.tar.xz And instructions to install it https://github.com/dnarvaez/archxo ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Arch Linux XO image and Sugar packages
Hello, I recently switched to Arch Linux and I put together a couple of things that others might find useful. * A trivial script to build minimal images for the XO. It builds a kernel from the OLPC git repository and put it together with prebuilt packages from the Arch Linux ARM project. It's enough to setup a wifi connection and install more stuff with pacman. It's XO 1.75 specific at the moment, but it should be easy to make it work on other versions. https://github.com/dnarvaez/archxo I will post a prebuilt image later. * AUR -git packages for the Sugar core and the browse activity. They makes it pretty easy to install the very latest sugar. (I tested them on my laptop, not on the XO yet). All of these are very much a work in progress. I'm posting them mostly because they might be of interest for Arch Linux users. Patches and bug reports both appreciated! -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar on Android via HTML5
On 13 September 2013 18:56, Manuel Quiñones ma...@laptop.org wrote: Just to clarify: 1. OLPC-A's intention is to create a HTML5+JS framework for creating Sugar Activities. A small correction: activities using web technologies has been discussed for a while in the Sugar community, and is now being actively implemented as part of Sugar roadmap. +1 (from someone not employed by OLPC) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar on Android via HTML5
Hi,
the full Sugar experience on Android is possible from a technological stand
point. Though it might require more development resources than we currently
have and/or it might require users to do thing they are uncomfortable with
like replacing Android, unlocking... There are a few approaches, with
different trade-offs.
Please avoid offlist!
On Tuesday, 10 September 2013, Sameer Verma wrote:
On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho
cbige...@hotmail.comjavascript:_e({}, 'cvml', 'cbige...@hotmail.com');
wrote:
Hi...
I have also been waiting patiently (well, not really very patiently) for
some news about Sugar coming to Android. So far, I have heard nothing new.
So I guess it isn't too late to throw my educator's opinion into the mix...
One of the things that makes Sugar the ideal learning platform for
children (and youth) is the wonderful compatibility of so many of the
Activities ... both from Activity to Activity and from student to student.
This facilitates the sort of learning we are all hoping to see more of...
creative problem solving, project based learning and cooperative learning.
Without this ability to integrate parts of projects, it would just be
another collection of apps.
Thanks for listening
Caryl
Hi Caryl,
Thanks for writing back. I am a bit surprised that I got more off-list
responses than on-list ones. I did not want to muddy the picture by
injecting my own viewpoint, but now that I've heard from others (on and off
list) it is clear that the split is driven by the role they play in the
ecosystem.
Most technologists have come up with reasons why they don't think a
complete Sugar experience would work on Android. Therefore, activities must
run like any other app on Android. On the other hand, as Caryl said,
Without this ability to integrate...it would just be a collection of
apps.
Somewhat knowing the limitations of what can be done with Sugar stuff on
Android, but disregarding that for a minute, I would say that Sugar as a
*platform* is an experience. It has a UI. It has a UX. Everything from the
Zoom interface to the activities to the Journal is Sugar. We have taken the
original Sugar on the OLPC XO experience and replicated that to the
classmate PC, SoaS, and other spins and distros, but in none of these cases
did we break the holistic Sugar experience. Now, along comes a popular OS,
and because the tech parts don't fit, we are advocating breaking up the
pieces and taking whatever flies. Memorize will become one of the few
hundred thousand apps on Android.
I disagree.
It's like saying we'll do the cat sprite from Scratch, but nothing else.
It's like saying we'll do the birds and pigs from Angry Birds, but not the
slingshot. Sugar, without all its pieces isn't worth the trouble. How it
will get done (if it will get done) is another story, and I wish we would
hear more about it onlist.
cheers,
Sameer
--
From: sve...@sfsu.edu javascript:_e({}, 'cvml', 'sve...@sfsu.edu');
Date: Thu, 5 Sep 2013 13:14:59 -0700
To: iaep@lists.sugarlabs.org javascript:_e({}, 'cvml',
'iaep@lists.sugarlabs.org');; de...@lists.laptop.org javascript:_e({},
'cvml', 'de...@lists.laptop.org');
Subject: [IAEP] Sugar on Android via HTML5
So, I've been mulling this for some time now. At work we are looking into
using FireFoxOS as a platform for HTML5 apps in some of our courses. It's
exciting that there is some momentum on the HTML5 activities in Sugar.
What I'm unsure about is the implementation. Outside of the classic Sugar
shell and activities (say, on a XO), are we envisioning the whole Sugar
experience on Android, UI and all, or are we looking to have Sugar
activities running on Android (with appropriate mods) but as yet another
app?
Has there been any conversation on this that I missed?
cheers,
Sameer
--
Sameer Verma, Ph.D.
Professor, Information Systems
San Francisco State University
http://verma.sfsu.edu/
http://commons.sfsu.edu/
http://olpcsf.org/
http://olpcjamaica.org.jm/
___ IAEP -- It's An Education
Project (not a laptop project!) IAEP@lists.sugarlabs.orgjavascript:_e({},
'cvml', 'IAEP@lists.sugarlabs.org');
http://lists.sugarlabs.org/listinfo/iaep
--
Daniel Narvaez
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar 0.99.1 (unstable)
Hello, this is the first feature frozen release. We landed all the features that we initially planned and a few more. Thanks to everyone involved! Highlights: * Multi selection in the journal * Service providers selection in the modem configuration * Previews in the object chooser * Multiple home views * Microformat activity updater * Automatic activity updates Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.99.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.99.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.99.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.99.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.99.3.tar.xz -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [ANNOUNCE] OLPC Hack '13 New Delhi
Cool! I'll try to be in irc.
On Friday, 24 May 2013, Anish Mangal wrote:
We are hosting the inaugural olpc/sugar New Delhi hacksprint on 8-9
June next month. We hope that this will help kiskstart a community of
passionate volunteers who will make positive contributions to the ecosystem.
Since you guys form an integral part of olpc/sugar, it would be great if
you could join us for the event. Part of the is an overnight hacksprint on
IRC (and possibly other forms of online collaboration). It would awesome if
you could make it here in person :)
We are also open to speakers who want to share their perspectives and
experiences to take the project further. Please head to hack.olpcdel.orgto
find out more. We can also be reached at
olpcde...@gmail.com javascript:_e({}, 'cvml', 'olpcde...@gmail.com');.
--
OLPC Delhi
--
Daniel Narvaez
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [Marketing] Sugar 0.100 or 1.0
Same thing, they also have system api. On 22 May 2013 21:23, Sameer Verma sve...@sfsu.edu wrote: On Tue, May 21, 2013 at 4:19 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 21 May 2013 23:32, Sameer Verma sve...@sfsu.edu wrote: Speaking of activities in the Sugar sense, I was wondering how many of the HTML5 apps from FirefoxOS would slide over to our platform with little change. I just got my hands on a Geeksphone Peak (http://www.geeksphone.com/) and have been following up on how Mozilla does FirefoxOS apps. (As an aside, their apps live on Github, both as code and as zip files, and hosted through https://marketplace.firefox.com/ which looks similar on the phone as it does on a laptop). If some of the FirefoxOS apps can become Sugar HTML5 activities, we may be able to ramp up on the number of activities relatively soon. Wishful thinking, and all that... Well, they won't work out of the box but it might be possible to port some of them if the source code is available. Difficulty depends on how Firefox specific their code is, aside from the usual rendering engine incompatibilities Firefox OS provides system APIs which are not available in Webkit. Ah! Didn't think of the system APIs. Well, then ChromeOS apps maybe? Sameer -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] Sugar 0.100 or 1.0
On 20 May 2013 12:19, Bastien b...@laptop.org wrote: Sean DALY sdaly...@gmail.com writes: I feel that 0.100 is even more unmarketable than 0.98. Agreed. Mathematically, it reads like a regression. Instead of reaching some definite level of maturity, it gives the signal that Sugar is in its early alpha (which is clearly wrong IMHO.) The problem is that Sean is also saying a 1.0 would be hard to market (without html activities, which I don't think are going to be solid at the first iteration). So I don't really know how we should call this release. Maybe 1.0 and we just don't make noise about it. Feels a bit like a lost opportunity though. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar 0.100 or 1.0
Hello, we need to decide if we want the next release to be 1.0 or 0.100. Here is the features we are planning for it. * Develop an HTML5 based toolkit for activities * Multiple selection in the Journal http://wiki.sugarlabs.org/go/Features/Multi_selection * Enhanced support for 3G modems http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support * Background customization http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view * Multiple home views http://wiki.sugarlabs.org/go/Features/Multiple_home_views * Integration with web services http://wiki.sugarlabs.org/go/Features/Web_services * Journal comments box http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view * Icon customization http://wiki.sugarlabs.org/go/Features/Icon_Change It's a bit of weird situation because code wise we are not really 1.0 ready. We are developing a new toolkit and the old one could use an API cleanup. On the other hand we are deployed to millions of users. Personally I don't really have a strong feeling. If the marketing team sees an opportunity in a 1.0 in October with the above feature list I'd say to go ahead with it even if from a developer point of view we are not ready. Otherwise we could delay it at least another cycle. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Marketing] Sugar 0.100 or 1.0
Thanks so much for the well thought feedback, Sean. On 17 May 2013 18:04, Sean DALY sdaly...@gmail.com wrote: We can't go with 1.0 unless we change the numbering system. The current system means it will take another decade to get to v3.0. I and perhaps others will have far more grey hair by then. Couple of things: 1 So this has never been discussed before with developers, but my opinion is that as soon as we have some automated tests in place we should move to continuous development. Which means version numbers would become pretty much irrelevant to developers. I'm not sure what other thinks and we probably shouldn't discuss that here to not sidetrack the thread. 2 All the power to marketing on this. I would be fine with you guys unilaterally choosing release numbers :) I proposed several years ago that the developer version numbers (not to mention the OLPC OS version numbers) be separated from the marketing version numbers, since the dev version numbers are unmarketable. Developer resistance at the time was ferocious, a symptom of how marketing is widely considered irrelevant in the F/LOSS universe. We therefore reoriented version numbering for Sugar on a Stick v6, which we rebaptized v1 Strawberry. This strategy helped us obtain very wide press coverage at the time, since journalists and analysts (as intended) understood that release as Sugar v1, a year after the spinoff from OLPC. This was appropriate, because Sugar was already shipping in production to hundreds of thousands of children. There is an important point here. At the moment the release we are talking about is not a finished product, which is what you seem to think about. It's just something you can take a make a finished product with. If we want to market a finished product we need to decide what that is. Is it Sugar on a Stick? Today, communicating a v1 of Sugar is problematic, *unless* it is associated with a platform change, e.g. the transition to HTML-based (and ultimately Android-compatible) Activities; or presented as positioning Sugar for tablets; our narrative would be a fresh start. I'm not too convinced the next release will be a compelling demo of the html libraries. We don't have much time to write new cool activities mostly. Maybe we can still market the switch, I'm not keen about that but I don't know. In terms of timing, it's far more important to offer real change with a v1 than to meet a self-imposed deadline; if more time is needed, by all means it should be taken. I think in a continuous development work we would basically release when we are ready. The code would be ready all the time and we would just decide when stuff is cool enough to make noise about it. Though realistically for development I don't think this is the time to abandon 6 months time based released. I suggest we discuss that after this release. It shouldn't make much difference for marketing, devel release doesn't even need to be public. A functioning HTML5 based toolkit, adapting to the form factor change towards tablets, Android compatibility (whatever form that may take), perhaps even an OEM partnership with Raspberry Pi Foundation or Google (Chromebook) or a social media giant, would not only greatly raise awareness, but provide a springboard for serious funding. Is anyone working on those partnerships? Is there anything developers can do to help them? Other than keeping to improve the software of course. And I'm sure a solid port to the Raspberry might be useful but... we need to chose what to focus on, it should something which has solid chances to happen. At the same time, it will be vital to communicate our level of ongoing support (in the wide sense) to the existing installed base which of course will include the XO-4 recipients as it starts shipping. I feel that 0.100 is even more unmarketable than 0.98. However, as a developer version number tucked away under the hood, I'd have no objection to that if it is helpful to getting the job done while a more understandable number is communicated to press and analysts. So perhaps we need to figure out what 1.0 (or whatever name marketing would like) should be and then developers will figure out the best way to make it happen :) The most pressing question to me is what it is that we are marketing exactly. Is it Sugar on a Stick? Is it the upstream code release (is that even marketable)? Or what is it? I hope it's clear I would like marketing to have more of a say in the development direction. I don't know where we want to go, but I wish you guys could help us to figure that out. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar 0.100 status report - April 22
Hello, we have made good progress in the last three weeks. Here are the highlights 1. Manuel submitted several bug fixes, which landed both on master and on the stable branch. It's great to see the gtk3 work being refined and completed. 2. The web services patches had a first round of reviews. Walter landed a localization fix that should be helpful to the Australia deployments. Ajay posted his journal multi-selection patch, it's a big one and we are trying to figure out how to best split it up for review. 3. I have been working on and off to get our code base ready for automated code checking and unit testing. The basics are getting in place, as soon they are solid enough we can start requiring new code to provide and pass tests. That should really improve quality and ease reviewers work. 4. The experiment with github pull requests continues. Walter already reported about it. I'll just add that we need people to help out more in that area, otherwise there is no tool which will solve our issues. 5. The research work on HTML activities is taking off. We had several discussion about how integrate them in the Sugar shell and how to implement communication with system services (like the datastore). http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042456.html Manuel is experimenting with the various javascript frameworks available to implement UI components http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042568.html https://github.com/manuq/components-test 6. We had our HTML activities kick off meeting today. A lot of people participated, thanks to everyone. The log is available http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27 We decided to base 0.100 work on WebKit2. If time permits we will implement compatibility with previous releases running WebKit1. Manuel is going to propose a strategy on UI components implementation. Lionel will make a proposal for the datastore API. I will look at communication between the Javascript code and the system. I will also try to take a look to collaboration API, though if someone else wished to research that it would be really helpful (anyone??). Chris pointed out that we should be designing our APIs keeping in mind we will want to port them to Android and other platforms in the future. It's important that we start writing HTML activities in parallel with the framework work. This is an area everyone can help with! Lionel is leading here and he wrote several already, Walter is also writing one. It would be good to try to port existing ones like Paint too. And it would be awesome to have nell-colors running inside Sugar. https://github.com/cscott/nell-colors -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future
On 13 April 2013 03:21, fors...@ozonline.com.au wrote: I would like to see all these questions discussed further. I would like the technical implementation discussions to be more contextualised in terms of user experience. Hi Tony, let me try contextualize, for what I know so far. I think these are the possible technical approaches to Sugar on Android (I'm going to simplify a lot, so this is not going to be exactly accurate). 1 Android kernel + Ported linux libraries + Sugar 2 Android kernel + Datastore/Collaboration replacement + Sugar rewritten in HTML 3 Full Android + Datastore/Collaboration replacement + Sugar activities rewritten in HTML 4 Full Android + Datastore/Collaboration replacement + Sugar activities rewritten with native Android API In terms of UX, 1 has only one major consequence. It will not possible to run Android and Sugar apps side by side. The rest would stay all the same. That would be the main consequence for 2 as well. Other small modifications might be required, for example the single instance stuff that started this thread. The change of toolkit will certainly have some consequences on the activities people will write, hard to predict but I'm hoping in a positive direction. I'd say html is much richer than gtk. So I'd say with 1 and 2 the goal is to keep pretty much the same user experience (although I think we should consider improvements while we are rewriting things). That's why the discussion so far has not been including UX considerations. Where UX would be interesting is with 3 and 4, as your questions shows. As far as I know these have not been researched much, or at least not discussed in detail on the mailing lists. I'm personally not very interested in them because I feel they would produce a bit of a UX monster and we would risk to lose what makes Sugar a compelling proposition (as described by Bert). Doing 2 would make it much easier to run Sugar activities on full Android, even if maybe with reduced functionality, and I would contempt with that. Anyway, I do think 3 and 4 are worth investigating, I'm just not going to do it myself. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future
On 13 April 2013 06:11, Martin Dengler mar...@martindengler.com wrote: On Sat, Apr 13, 2013 at 11:25:46AM +0800, Martin Dengler wrote: I bet someone (cscott?) has already investigated [porting Sugar to Android] Answering myself: http://www.google-melange.com/gci/work/download/google/gci2012/7972209?id=17001 Just as a note of caution, that document contains several inaccuracies. For example, telepathy is not built on python. The problem with GTK is not really the compiler. etc. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future
On 13 April 2013 06:11, Martin Dengler mar...@martindengler.com wrote: On Sat, Apr 13, 2013 at 11:25:46AM +0800, Martin Dengler wrote: I bet someone (cscott?) has already investigated [porting Sugar to Android] Answering myself: http://www.google-melange.com/gci/work/download/google/gci2012/7972209?id=17001 Scott investigated this too http://cananian.livejournal.com/62756.html There are several posts on the blog about it. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future
On 13 April 2013 15:37, fors...@ozonline.com.au wrote: 1 Android kernel + Ported linux libraries + Sugar 2 Android kernel + Datastore/Collaboration replacement + Sugar rewritten in HTML 3 Full Android + Datastore/Collaboration replacement + Sugar activities rewritten in HTML 4 Full Android + Datastore/Collaboration replacement + Sugar activities rewritten with native Android API Thanks Daniel That explains things for me. I was not fully understanding the technical discussions. With options 1 2 a lot of existing functionality could be lost: The phone (unless a Sugar dialer was written) The alarm clock (unless a Sugar one written) Skype Some power management controls Airplane mode/wifi/phone modem controls Facial recognition screensaver delay Multiple file selection Excel spreadsheet viewer Anything we need Gnome to do on an XO Lots more A lot of Android devices are going to come into the posession of kids in developing countries, cheap second hand devices, old phones etc. Millions of them. Options 12 are not likely to be installed because they will result in a significant loss of functionality. Purchases of new tablets by government education departments with options 12 is viable. My guess is that cheap privately owned devices will outnumber education department devices by orders of magnitude. The privately held devices will also be used in a way that is more consistent with Sugar principles, experimentally and playfully, the education department devices may well be locked down. It would be good if Sugar's affordances for playful learning could exist alongside the full Android. I understand that we may not have the resources to do this. Hi Tony, I certainly understand this point of view... Most of the features you are mentioning could be implemented also with the 1/2 approach too but certainly we would get there a lot more slowly. And you are right that having to install a custom OS is a barrier than *lots* of people will never cross. I want it to be clear that the preference for 1/2 is just my personal inclination. I know of people that would like to research 3 when they find the time. Also most of the work towards 2 is also useful for 3, one doesn't exclude the other. Actually, in an ideal world, I think we would do both 2 and 3, it's just a matter of resources. A part of the work which has been discussed for the next release is useful to both 2 and 3, the other part is integration with the current OS, to not leave it behind. So I don't think we are going to make a call between 2 and 3 soon. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] [support-gang] Fwd: Re: Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 12 April 2013 23:40, Caryl Bigenho cbige...@hotmail.com wrote: Would it be possible to, instead of trying to port all of Sugar to Android, start with a few key Activities? I think that's the idea. Porting the whole Sugar to Android would involve porting a lot of system components and then likely having to maintain the ports. Too big and difficult of a task for our community, in my opinion. If someone who is a whiz at this sort of thing could write something similar to James Simmons, Make Your Own Sugar Activities, about how to convert a Sugar Activity to run on Android, then other programmers could get involved in working on them... both individually and in groups. Unfortunately porting an activity to Android means rewriting it from scratch. Depending on the activity there might be pieces of code which are general enough to require just a python - javascript translation. Btw the idea is to port to html5 and javascript, not to the Android native API. The advantage is to be able to run the same code on other OSes but of course integration with the Android platform might suffer. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)
Hi Anish, that's interesting. First impressions from a quick look. There isn't really much documentation so I won't promise this is fully accurate :) Ubuntu is running in a chroot on the top of a modified android kernel. That's a bit of an hack and I wouldn't recommend it if we had to maintain the thing. Though having a company, and another community, deal with the mess makes it more viable. They don't have X11 but apparently they ported gtk3 to mir. So at least gtk activities should be fine. It's not possible to run Android applications along linux ones but an OLPC like dual desktop thing might be possible in the future. I think this should be investigated. It might be possible to run Sugar on it without major modifications. On 13 April 2013 00:28, Anish Mangal an...@sugarlabs.org wrote: Hi Daniel, et. al., Do you think Ubuntu could be an (easier) option for sugar to piggyback upon... This is not a because-i-think-ubuntu-is-cool opinion, but testament to the fact that canonical have been working to get ubuntu running on tablets and smartphones. https://wiki.ubuntu.com/Nexus7/Installation Even I'm not sold on the idea, but I guess it should be part a discussion and research efforts concerning sugar's future. Best, Anish On Fri, Apr 12, 2013 at 6:09 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 12 April 2013 22:52, Sean DALY sdaly...@gmail.com wrote: The initial work seems very encouraging, yet it seems Sugar Labs doesn't currently have the resources to make an Android offer available anytime soon. But: now is the time. I believe fundraising is vital to achieve this goal, at the very least to facilitate face to face Sugar Camps for the community. I have ideas how to go about this, but I agree the community needs to be clear about where we are going. An Android offer would of course be of great interest to OLPC. To be completely honest, I think a migration to HTML/Android is never going to happen unless someone invests in it *and* the community rallies around that effort. Even a small team of experienced, full time developers could lay the framework foundations. And then writing enough activities for the framework to be of any interest would take a *lot* of work from the community. But are there the conditions for that to happen? There are also initiatives we could take to multiply the size of the community. In particular, support for the Raspberry Pi (which has topped 1 million units in sales - half of these since September -, is shipped without an OS, and is arriving in junior high and high school computer science classes) could be an ideal OEM platform for Sugar. I also see Raspberry PI as a tempting opportunity. Though I think there is some conflict between trying to extend the reach of the current platform and bootstrapping a new one. I think it's important for people to understand that porting to Android is not really porting but a full rewrite. We can reuse designs, artwork, ideas and some of the experience we made so far, but no code at all. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Anish | an...@sugarlabs.org -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)
On 13 April 2013 01:36, Daniel Narvaez dwnarv...@gmail.com wrote: Hi Anish, that's interesting. First impressions from a quick look. There isn't really much documentation so I won't promise this is fully accurate :) Ubuntu is running in a chroot on the top of a modified android kernel. That's a bit of an hack and I wouldn't recommend it if we had to maintain the thing. Though having a company, and another community, deal with the mess makes it more viable. They don't have X11 but apparently they ported gtk3 to mir. So at least gtk activities should be fine. It's not possible to run Android applications along linux ones but an OLPC like dual desktop thing might be possible in the future. Bah, it looks like gtk3 support is planned for 13.09 but not there yet. https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged So nothing to see for at least a few months. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Sugar 0.100 status report - April 2
Hello, I will try to send out regular reports about the progress of the 0.100 release, weekly, bi-weekly or monthly depending on how much is happening. 1. A bit late, but we finally have a schedule for the release.We are not going to have a feature acceptance deadline this time. We decided to have that discussion early, to try and narrow the focus of the release. http://wiki.sugarlabs.org/go/0.100/Roadmap 2. In parallel some developers will keep to refine the 0.98 series. Help is welcome on that effort. While perhaps not as exciting as new features, bug fixing and polish is essential to good software. 3. The main goal of the 0.100 release will be to the develop an HTML5 based toolkit for activities. This will facilitate running Sugar activities on other platforms, like Android. In addition we are planning to land several other features which has seen development in the past few months Multiple selection in the Journal http://wiki.sugarlabs.org/go/Features/Multi_selection Enhanced support for 3G modems http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support Background customization http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view Multiple home views http://wiki.sugarlabs.org/go/Features/Multiple_home_views Integration with web services http://wiki.sugarlabs.org/go/Features/Web_services Journal comments box http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view Icon customization http://wiki.sugarlabs.org/go/Features/Icon_Change 4. The project has always had a bit of an issue with submitted code being timely reviewed. The situation got worse in the last few months. This is a major blocker for contributions and we are trying to improve. Simon and Manuel, which currently maintains all the Glucose modules alone, are putting together a list of reviewers to help them out with the task. We are also trying to find review tools which will allow the process to be both trackable and visible to everyone (and hopefully a bit more pleasant too!). We have so far mostly experimented with a workflow based on github pull requests. 5. Walter Bender landed several patches to add a comment box to journal entries. It will be populated both by the Portfolio activity and by the web services integration which is being worked on. The obligatory screenshot http://wiki.sugarlabs.org/images/4/4a/FB-comments.png 6. All in all I think we made great progress planning the next release. But we will need everyone help to execute and make it a really good one. -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar on Android (was Questions for SCaLE 11X)
On 21 February 2013 09:35, Ron Feigenblatt doc...@gmail.com wrote: The big news is that OLPC reports potential buyers have expressed interest in Android, so it has a plan to move the XO-4 that way by YE2013. This poses an implicit challenge to Sugar Labs, namely, could Sugar sit on top of Android rather than Linux Fedora by then? I think that's never going to happen unless we come up with a plan. There have been a couple of isolated efforts that would lead there at some point, but I'm not aware of even a discussion about it on the devel mailing list. It's not going to be trivial at all. I have my strong opinions about how we should get there and I've been posting on sugar-devel about the work I'm doing. But other approaches are possible. I just hope people will realize that it's urgent to do something about this and that we need with a concerted effort. It's not going to magically happen :) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] Raspberry PI
Perhaps a good opportunity to get Sugar in the hands of more kids http://www.guardian.co.uk/technology/2013/jan/29/google-raspberry-pi-s -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Raspberry PI
That's what I expected but we need to lower the barrier to get it running. I heard something about it on the mailing list but now I can't even find anything useful by searching google and the wiki (I didn't try too hard, but the point is that I shouldn't have to). A bit radical, but I think our current downloads page should burn in hell. On a new one there should be a Raspberry PI which would read something like * Insert an SD card into a PC (at least X GB) * Run _this (link to an executable file including the image)_ * Insert the SD card in the Rasperry and turn it on Then I think we could make noise about it and probably a lot of people would try it out. More in general, if something is not that simple, I don't think it should be on the main download page. I know the page would be empty right now, but that's exactly the problem. On Wednesday, 30 January 2013, Peter Robinson wrote: It already works fine on the Fedora releases for Sugar. Peter On Tue, Jan 29, 2013 at 10:46 PM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: Perhaps a good opportunity to get Sugar in the hands of more kids http://www.guardian.co.uk/technology/2013/jan/29/google-raspberry-pi-s -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org javascript:; http://lists.sugarlabs.org/listinfo/iaep -- Daniel Narvaez ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar Digest 2012-11-25
On 26 November 2012 02:34, Daniel Francis fran...@sugarlabs.org wrote: On Sun, 25 Nov 2012 19:43:35 -0500 Walter Bender walter.ben...@gmail.com wrote: 3. Daniel Narvaez has made a number of improvements to sugar-build [5], which has by-and-large replaced sugar-jhbuild as the preferred development environment for Fedora and Ubuntu. Congratulations to Daniel Narvaez, who does this very important work. Specially where jhbuild stops to work properly always. Something I don't like completely is that people can contribute to Sugar only from Ubuntu or Fedora, but knowing that jhbuild stopped working in Ubuntu and Debian, it's a terrific improvement. A new important step would be support other up-to-date GNU/Linux distros souch as Debian Testing, ArchLinux, Gentoo, et al. But that should come from the Sugar contributors who use those other distros. Hi, I agree with both your points here. It would be important to support more distributions and someone else needs to step in for that to be possible. To facilitate this, I'm streamlining a bit the process of adding a distribution and documenting it. I will post a link to the docs as soon as I have it. I'm also be available to help out whoever is interested in contributing support for a new distribution. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Sugar Digest 2012-11-25
On 26 November 2012 15:58, Samy Boutayeb s.bouta...@free.fr wrote: Le lundi 26 novembre 2012 à 15:36 +0100, Daniel Narvaez a écrit : On 26 November 2012 02:34, Daniel Francis fran...@sugarlabs.org wrote: On Sun, 25 Nov 2012 19:43:35 -0500 Walter Bender walter.ben...@gmail.com wrote: 3. Daniel Narvaez has made a number of improvements to sugar-build [5], which has by-and-large replaced sugar-jhbuild as the preferred development environment for Fedora and Ubuntu. Congratulations to Daniel Narvaez, who does this very important work. Specially where jhbuild stops to work properly always. Here, in Debian wheezy/sid, jbuild build without blocking issue, whereas jhbuild failed building terminal, ending up with non buildable components (meta-fructose, meta-sugar, terminal) So, with build, for example, the icons in the UI are at least visible and core activities such as TurtleArt are functional. That's good news, it should not be too difficult to add support for it then. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
