[Sugar-devel] some efforts that would be really useful for deployments
tomeu at sugarlabs.org
Sun Dec 6 16:19:46 EST 2009
2009/11/25 Daniel Drake <dsd at laptop.org>:
> 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
Thanks for doing this, I think it really helps to ping people until
the important stuff gets finally done.
> 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
> 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
> 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.
> 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.
> 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
> And speaking now from a "Sugar implementor" standpoint, here are 2 fully
> specced features which have yet too see much attention:
> Any takers? :)
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
More information about the Sugar-devel