[Sugar-devel] The Future of Sugar on a Stick

[Philippe Clérié]

+1

I made a similar suggestion a couple of weeks back. 

Thinking as someone who will probably be in it up to his neck, on the 
teaching side, what I would like to see is a polished distribution, 
installable on a hard disk, released once a year around April-May. That will 
give me all summer to evaluate and plan for the upgrade come fall. Then only 
security and bug fixes. I would probably use the fall release of Fedora as a 
base.

-- 


Philippe

------
The trouble with common sense is that it is so uncommon.
<Anonymous>

On Monday 14 September 2009 10:32:55 Sebastian Dziallas wrote:
> This document is an open letter written to the Sugar Labs community. It
> is an attempt to clear up the recent confusion about SoaS and let
> community members know what SoaS is, what our goals are with regards to
> it, and what possibilities we're considering for the future - both
> technical and organizational - direction of the project. With the next
> release of SoaS coming up in about three months, we also want to have
> this discussion with our current release schedule in mind.
> 
> == What is SoaS? ==
> 
> Sugar on a Stick (SoaS) is a Linux distribution that enables kids to
> reclaim computers for themselves in a world of computers made and
> managed for and by adults. SoaS aims to make it easy for local deployers
> to provide each student with a thumbdrive (stick), which can be booted
> into the student's personalized Sugar environment from any machine.
> Thus, SoaS advances in achieving its goal of giving each child in the
> world access to its free and open source learning environment to create,
> explore, reflect, and collaborate on any machine - at school, at home,
> and elsewhere.
> 
> Values:
> 
> * Customizability - Deployments, as well as users, should be able to
> build their own SoaS easily. It is crucial for the success of SoaS to
> allow modifications and to make the process of creating derivates as
> easy as possible.
> 
> * Deployability - SoaS must be easy to deploy. It should take as little
> effort as possible to get to a working system, both for individual
> sticks and for bigger deployments in computer labs.
> 
> * Local Support - We must encourage and foster the growth of local
> community support for deployments. If we build things in a way that
> means deployers can't fix most of their own problems, we're doing
> something wrong.
> 
> A note on deployability: We want SoaS to always be the easiest Sugar
> deployment option to support, which becomes more and more important as
> the product matures and is used by more schools and teachers. In order
> to properly support SoaS users, it is important that the upstream
> components of the project also be well-supported, and that we have a
> strong relationship with each upstream, especially our current base
> system - Fedora, so we can rapidly resolve any issues that may arise.
> 
> But SoaS is not mature yet. It currently consists of various
> technologies thrown together into a first working version of a product,
> resulting in a number of inconsistent hacks. While we have been actively
> trying to follow upstream development - for example within our major
> component, Fedora - as much as possible, we didn't always succed here.
> The more development took place, solutions got hacked up, causing a
> difficulty of maintance in general. With the next release of SoaS coming
> up in about three months, we are working on reducing these issues now.
> 
> One of these issues mentioned earlier is affecting users through the
> possibility of installing and directly deploying SoaS. Right now,
> teachers have to look for their own solutions to get SoaS in place,
> which is a situation we want to change: Ideally, they would be able to
> use a well-designed interface for installations and deployments.
> 
> On the other hand, the structure around SoaS is rather loose: decisions
> tend to happen spontaneously on various mailing lists (since there is no
> dedicated one), as well as in IRC channels. To create a place where the
> project itself lives, to advance in realizing technical innovations, we
> need such a mailing list - as well as a development team. Yes, we need a
> SoaS development team for being able to implement all the cool things
> out there. And since I don't have the bandwidth to handle all of this
> myself and open source is about sharing experiences, about working
> together, we need to find a good way of letting more people participate
> in the process of working on SoaS.
> 
> Following the goals and visions stated above, the subsequent short-term
> steps for SoaS are outlined below, with the goal in mind to become a SL
> project. However, the technical communication will proceed on the newly
> created mailing list and on Launchpad, whose pilot usage as our bug
> tracker will continue, too.
> 
> Short Term Action Items:
> * We create a SoaS mailing list.
> * We establish the SoaS development team.
> 
> Thanks,
> Sebastian Dziallas
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>