[IAEP] [Sugar-devel] Future of Zero Sugar

[Daniel Drake]

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-devel@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