[Sugar-devel] some efforts that would be really useful for deployments

[Daniel Drake]

Hi,

After revisiting some of the changes I have made to the software while
working on deployments I just wanted to post the list again as a
refresher.

I have not had enough time to do the appropriate master-level QA on
these, or to get them running on the latest Sugar versions. I hope that
some people will consider taking on these tasks.

Some of the items here are far from trivial and will require design and
thought to fix properly. Some of the items below are not purely sugar
tasks. But at the same time they are really big items for sugar
deployments. (Just to throw in some opinion here too, I feel that all
deployments would benefit from more time being spent working on
deployment technologies and realities at the system level -- Sugar 0.82
reached a point where the biggest problems you find in the field are far
outside of the UI/activities level, now we have to attack the others)



Customizing browse homepage
The procedure to do this is too complicated for most deployments, and is
undocumented.

Customizing which activities are in the favourites view by default
You can do this just by editing a file, but that file is a part of the
sugar distribution so it will be lost on upgrades.
There is also no documentation for how to do this, as far as I can see.

Automatic activity upgrading
Activity updating is too difficult for young children to understand and
is very hard to coordinate across a classroom.
This one I have never had time to hack a fix into place.
Also the "You should upgrade your activities" notice needs to die.

Unregistering from an XSes / registering with multiple XSes
A hack available here: http://dev.sugarlabs.org/ticket/362
Still no user-friendly or documented way of doing this.

Full journal restore, and backup control
http://dev.laptop.org/ticket/9250
We still don't have a good way of browsing backups or restoring multiple
files (e.g. the whole journal) in 1 go.

Another constant headache is with translations. How do you roll out new
translations for old software? The best we have right now is language
packs but they install files which conflict with both system packages
and activity bundles. And they are difficult for deployments because you
need Linux skills to execute them.

Registration is a real headache in classrooms right now. It's just a bit
of an alien concept for new computer users. And it's so difficult. If
you try to register before connecting then a bug somewhere means that
you can't even complete a successful registration after connecting --
you have to restart sugar. And then after you do register you have to
restart sugar for it to take effect.
http://dev.sugarlabs.org/ticket/1151

But why do we force users through the pains of registering at all? We
control all the technical bits, lets automate it to hunt down the
specific school server and register.
http://dev.sugarlabs.org/ticket/1152

And once we're that far, why do users have to select which network to
connect to?  This is also a significant classroom challenge. But
typically in deployments, networks are installed at the same time that
the sugar systems are made available. It's all controlled by the same
party. So we could have a way that deployers could make sugar
automatically connect to specific networks, or something like that.

During activity update, only download the parts that have changed
http://dev.sugarlabs.org/ticket/1499


And speaking now from a "Sugar implementor" standpoint, here are 2 fully
specced features which have yet too see much attention:

http://wiki.sugarlabs.org/go/Features/Font_configuration
http://wiki.sugarlabs.org/go/Features/Content_support



Any takers? :)

Daniel