+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 > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
