[sugar] Development environment for newcomers

[Ian Bicking]

drew einhorn wrote:
> My friend Larry Landis and I were at PyCon, but were unable to stay
> for the sprints.
> 
> We were thinking about starting a similar project in a couple of weeks
> when he gets back from a gig in Italy.
> 
> Since I got back from PyCon I have been fooling around with
> sugar-jhbuild off and on.  Gave it a lot more time and energy
> this weekend.
> 
> I agree that sugar-jhbuild is not suitable for beginners to
> install on their computers.  In addition to taking way too
> long to compile (on an average box) and download
> (if you are bandwidth deprived, like me), it is way to unstable
> for beginners.  Something that worked yesterday may not
> work today, once the latest source with new bugs is
> retrieved by subversion or git.

Yes; sugar-jhbuild is useful if you are developing Sugar, but less so if 
you are developing on Sugar.  Well, more than "less so", it's quite 
distracting to worry about the underlying platform.

> We will probably need a different balance between stability
> and bleeding edge for sugar itself and the develpment
> enviornment generated by:
> 
>     ./sugar-jhbuild build-base
> 
> I think preparing a pre-built development environment on a
> hefty server box that can support a reasonable number of
> beginners is the way to go.
> 
> We could create an account for them to ssh into if they
> are comfortable with the command line.  We could use
> ltsp if they need gui-based tools, with freenx if the need
> to access the gui over a low bandwidth link.

I would be reluctant to start down the path of building this kind of 
infrastructure.  Mostly because it's a pain in the butt, and I'm not 
sure it satisfies the basic needs for a beginning (OLPC) developer.

> I have a dim recollection of a unionfs on OpenBSD,
> but those guys are way too hostile.  But the Wikipedia
> gives me some other ideas:
> 
>      http://en.wikipedia.org/wiki/UnionFS
> 
> We could do a three layer unionfs, the base layer could be a
> read only file system with the standard development environment,
> each user could have their own read-write lay on top of it in their
> home directory, so any modifications they make would be their
> own and persistent, and a memory resident cache on top for
> performance (if the serve has enough ram).  Or maybe we only
> have two layers and do the caching some other way.

It would also be helpful if the image could mount a network drive (from 
the host) over the image's own drive, thus allowing the host system to 
edit an file, and also revert those changes fairly simply.  I think(?) 
that Bitfrost involves this same sort of overlay, so maybe the 
functionality is already there in the images?  (Or due soon)

> Guido has been frustrated trying to get sugar-jhbuild running on
> his Ubuntu Dapper box, and kicked off a discussion about what
> OS would be best if he decides to build a new box to use
> for sugar development.  We should pay attention to that thread.
> I have not yet looked to see if he has gotten any responses.
> I think Ubuntu Edgy, Feisty, and Fedora Core 6 will be in the
> running.  I have no idea if any of them support a unionfs.

This would be useful at least for the image that Michael is trying to 
build, where we could give people a working live CD based on a system. 
Ideally it would be built so people won't have Any Problems At All. 
He's been blogging his progress over at http://blog.vrplumber.com/ -- I 
think he might actually be using Gentoo?  Hm.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org