On Tue, 2009-12-15 at 06:07 +0000, Aleksey Lim wrote: > * as a 3rd party developer, I don't see such teachers requests listed > somewhere on wiki, that let me see what can I do and peek most > interesting/suitable-for-my-skils/etc task
There's enough going around that you could work on which would be a huge benefit to deployments. Here are a few ideas. We know about projects from Paraguay and Uruguay implementing 3G support. Why not step in early and review their code and send them some patches? Look for bug reports from Soas developers and users, and OLPC too. These people are likely closer to deployments than you are. Here are OLPC ones: http://dev.laptop.org/report/43 (you'll have to filter the list) You could perhaps try and put yourself into a role where you address these needs on an ongoing basis. This would be a dream come true for deployers and distributors. Some more project ideas here: http://www.mail-archive.com/sugar-de...@lists.sugarlabs.org/msg10631.html Documentation: there's very little good documentation on how to deploy sugar in a classroom scenario. If you were to start some documentation, not only would it be a huge help for deployments, it would also make you think more about the real-life challenges which may lead to some development projects. Bryan's point about Sugar not supporting the classroom scenario of handing work to your teacher is a good one. Some things that I think would be of large benefit: Supporting the mass of content that has already been generated: http://wiki.sugarlabs.org/go/Features/Content_support This would help simplify ad-hoc networking: http://lists.laptop.org/pipermail/devel/2009-December/026831.html This is a biggie: http://bugs.sugarlabs.org/ticket/1608 I suspect this flicker is going to be quite disruptive for field users: http://bugs.sugarlabs.org/ticket/1596 F11-for-XO1 work would be of a huge impact to the largest part of sugar's current userbase. Right now they cannot receive any of the improvements you make to sugar because the project is not (quite) stable enough for deployments. It has a buildmaster but not much development progress apart from the bits that can be directly picked up from OLPC's XO-1.5 work. We seem to even lack good diagnosis of the outstanding problems. You could look at Sayamindu's recent tickets on bugs.sugarlabs.org. We have identified various places where sugar cannot gracefully deal with corruption. I believe there are still various well-known 0.86 regressions (over 0.84). For example, Record not working. These regressions are going to be a huge headache to anyone who tries to upgrade, perhaps you could squash a few of those. OLPC mesh: NM-0.8 now supports this, sugar patch needs to be brushed up and merged. And help backporting the patches to NM-0.7 would be useful too. > * I'm feeling huge discomfort as a developer when I need to package > binary blobs to my .xo, w/o instrument which let me unify > installing/upgrading process of such non-SP/specific-to-my-activity > dependencies I feel this too. But you can solve it with less drastic changes. Which you seemed to be doing already. I've read briefly over your various 0install feature proposals and I've yet to form an opinion on the technology. I need to read them again, but at least on my quick reads, I'm still left unaware what the user experience will be like, nor the developer experience, and what the inefficiencies of the system will be. Daniel _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep