Hi, I think one possible place where we are having a miss communication is about what is "Sugar on a Stick" or SoaS. I think to Sean and I it is a solution that can be used in schools. It includes the code for the stick, a core set of activities that are known to work, stick backup, restore and software update, easy and relatively foolproof ability to create sticks, information on how to implement, clear documentation on what hardware is likely to work and the variety of ways of interacting with hardware including boot-helpers on CD and Diskette and Virtual Machines. In addition we will start really interacting with Learners and Teachers and that is where we will really learn, test and improve our total solution. Thus if you look at the SoaS code snapshot its pretty stable but if you look at the full solution its still under very rapid development and we expect the Teacher and School IT person's user experience to change dramatically between June and Sept and probably again by Q1 2010. So is there a naming solution that accurately communicates to other Open Source Developers the stability of the SoaS.iso code base but also accurately communicates to nondevelopers the rapid progress and improvements and additional features that the total solution is undergoing over the next 6 months? Thanks, Caroline <div class="gmail_quote">On Wed, May 27, 2009 at 8:24 AM, David Farning <<a href="mailto:dfarning@sugarlabs.org">dfarning@sugarlabs.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class="h5"> Sorry, This thread fell off the public mailing list. My fingers are a little too big for the keyboard on my new lenovo s10. I keep hitting enter instead of shift:( david ---------- Forwarded message ---------- From: David Farning <<a href="mailto:dfarning@sugarlabs.org">dfarning@sugarlabs.org</a>> Date: Tue, May 26, 2009 at 9:43 AM Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! To: Caroline Meeks <<a href="mailto:caroline@solutiongrove.com">caroline@solutiongrove.com</a>> Cc: Sean DALY <<a href="http://sdaly.be" target="_blank">sdaly.be</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>>, Sebastian Dziallas <<a href="mailto:sdz@sugarlabs.org">sdz@sugarlabs.org</a>>, Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>>, Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>>, Bernie Innocenti <<a href="mailto:bernie@codewiz.org">bernie@codewiz.org</a>>, Simon Schampijer <<a href="mailto:simon@schampijer.de">simon@schampijer.de</a>>, Greg Dekoenigsberg <<a href="mailto:gdk@redhat.com">gdk@redhat.com</a>> We are running into 2 classical community supported project conundrums. 1. If you call a release stable, more people will use it - encouraging more testers. Yet, by calling it stable it raises expectations. 2. Who determines when something is ready? The answer to 2 is easier. _All_ platform level decisions are driven by developers. Those developers must agree on a release cycle which is supported by a release manager. It might seem counter intuitive, but in the long run the quality of the release cycle is more important than the quality of a given release. If we focus on the cycle we get a steadily improving product and community. I would suggest that you have an irc meeting which includes at least: Simon - experienced release manager. Sebastian - lead SoaS developer. Caroline - SoaS project lead. Greg - Old grey bearded man. Sorry Sean, you and I are not invited:) The release cycle is a technical decision made by technical contributors. You, Walter, and I need to step back and trust the developers to make the correct technical decisions. Otherwise we get a tail wagging the dog situation. These individuals need to set a release schedule and appoint a release manager a with the authority to enforce the scheudal. The challenge SoaS faces is that it is a down stream project based on sugar -> fedora -> soas . Quite honestly, I really don't see all that much difference in the log run on which release date is chosen. The import bit is that we set _a_ date and stick to it so all contributors and downstreams can depend and synchronize around that date. david On Tue, May 26, 2009 at 9:01 AM, Caroline Meeks <<a href="mailto:caroline@solutiongrove.com">caroline@solutiongrove.com</a>> wrote: > Hi, > > A couple of questions. > > Sebastian and Sean, please each define what the terms "Beta" "Release > Candidate" and "Version 1" mean to you. I wonder if we have different > definitions. Perhaps if we understood what those were we could find the > right compromise. > > Sebastian, I absolutely agree we want kids trying SoaS this summer. Please > explain your reasoning that releasing V1 in the Summer will result in more > summer testing then Beta-2 and maybe we can again find a way to meet > everyone's concerns. > > Thanks, > Caroline > > On Tue, May 26, 2009 at 9:49 AM, Sean DALY <<a href="http://sdaly.be" target="_blank">sdaly.be</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>> wrote: >> >> I'm sorry we're not as connected as we should be (I'm the first to >> admit I have a learning curve concerning dependencies/upstream etc.) >> but in fact... my impression *was* that SoaS v1 would be v0.86 over >> F12! >> >> Put simply, for SoaS to be classroom-ready, teachers need a >> minimum-fuss solution... we just can't count on them spending time >> troubleshooting. >> >> If you remember the discussions about the numbering system... the idea >> behind SoaS "beta" and "v1" was to simplify numbering (and generate >> buzz) by disassociating the Sugar version 0.xx / Fedora version 1x. >> Teachers won't care if it's Sugar v0.84/F11 or v0.86/F12, but they >> will care if it works or not on what they have, and can help them in >> the classroom by offering a choice of Activities. >> >> Many teachers have Macs... some Intel, many PPC I'm afraid... if the >> lack of a machine is a blocker, I'll buy and ship you a Mac Mini (I've >> bought half a dozen XOs and as many netbooks for testing at this >> point, and I am trying to negotiate loaners too). >> >> Concerning exotic hardware (and some netbooks have very exotic >> hardware), I don't see the difficulty in contacting OEMs, telling them >> we have the best K-8 learning platform available, and could they >> please help us make their machine run Sugar correctly. I am sure every >> OEM is watching Dell's strategic education netbook launch very >> closely. >> >> The probability of success of SoaS in the classroom will be raised if >> we can at least point teachers in the direction of a school server. I >> just bought a ShuttlePC and Martin Langhoff will be installing an XS >> server on it, I want to find out how adaptible it could be to SoaS >> machines. I plan to have it ready for LinuxTag. >> >> It's difficult as we grow to keep abreast of what everyone is doing... >> I don't remember a request for RC feature requests (I didn't think we >> were that far along), but I'm sure it happened at some point from what >> you said. We could announce backup/school server support for a v2 and >> that wouldn't shock anyone, but if SoaS isn't very reliable we'll have >> another mountain to climb for a v2. >> >> I have found the best solution is to subscribe to all of the lists, >> and read messages even if I don't understand everything (and I don't). >> We have a marketing challenge to overcome: lots of very negative press >> about OLPC... for example a wire service journalist recently referred >> to the XO as "mythical", implying it was never even manufactured! The >> best way to turn the tide of criticism is to build up to a solid >> release. Any misstep will be pounced upon :-( >> >> I am concerned that we seem to have few testers. We even set up >> <a href="mailto:feedback@sugarlabs.org">feedback@sugarlabs.org</a> to lower the barrier for bug reporting, but no >> one has used it yet. There may be thousands of G1G1 donors who would >> gladly help us test SoaS with their XO-1 (I'd be the first to try), >> but to do that we need a simplified test protocol. Which can be done, >> but not immediately. >> >> We can achieve a reliable method for loading sticks by the fall, or in >> the worst case we could work with partners such as <a href="http://on-disk.com" target="_blank">on-disk.com</a>, but >> it's a blocker problem that needs to be solved. I bought three of my >> test netbooks with Windows (first time since 1998) just to be able to >> run and test the liveusb creator. >> >> I would suggest the LinuxTag release stay "beta-2" or "Release >> Candidate" as planned, which will give us precious months to make a >> big launch in the fall... on an improved platform. >> >> Perhaps Caroline as SoaS project manager you could organize meetings >> to help us all get on the same page? >> >> thanks >> >> Sean >> >> >> On Tue, May 26, 2009 at 3:13 PM, Sebastian Dziallas <<a href="mailto:sebastian@when.com">sebastian@when.com</a>> >> wrote: >> > Another side-note: It could also be possible to push the next SoaS >> > release >> > with with F12 and Sugar 0.86 with a big splash and have this still as >> > v1! >> > Just thinking... >> > >> > --Sebastian >> > >> > -------- Original-Nachricht -------- >> > Betreff: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! >> > Datum: Tue, 26 May 2009 15:10:09 +0200 >> > Von: Sebastian Dziallas <<a href="mailto:sebastian@when.com">sebastian@when.com</a>> >> > Antwort an: Sebastian Dziallas <<a href="mailto:sdz@sugarlabs.org">sdz@sugarlabs.org</a>> >> > An: Sean DALY <<a href="http://sdaly.be" target="_blank">sdaly.be</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>> >> > CC: Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>>, Caroline Meeks >> > <<a href="mailto:caroline@solutiongrove.com">caroline@solutiongrove.com</a>>, David Farning <<a href="mailto:dfarning@sugarlabs.org">dfarning@sugarlabs.org</a>>, >> > Tomeu >> > Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>>, Bernie Innocenti <<a href="mailto:bernie@codewiz.org">bernie@codewiz.org</a>>, >> > Simon >> > Schampijer <<a href="mailto:simon@schampijer.de">simon@schampijer.de</a>>, Greg Dekoenigsberg <<a href="mailto:gdk@redhat.com">gdk@redhat.com</a>> >> > >> > [cc += Greg & Simon] >> > >> > Hi everybody, >> > >> > let me explain this a little bit more (I'll be around on IRC later this >> > evening). There are some points I clearly need to make. >> > >> > Sean DALY wrote: >> >> >> >> Hi Sebastian >> >> >> >> hmmm... we've been announcing SoaS v1 for "Q3" for some time now >> >> (<a href="http://www.sugarlabs.org/press%29." target="_blank">http://www.sugarlabs.org/press).</a>.. the idea being that v1 will boot >> >> just about anything. Reliability is extremely important... if a single >> >> journalist can't boot their PC with it, we're in trouble, it will have >> >> a reputation for being "buggy" which, once gained, is very, very >> >> difficult to shake. No one cares about bugs if we are in beta, but >> >> they sure will if we present v1 as classroom-ready. >> > >> > I'm well aware of the Q3 date. Who has decided that? When was it >> > decided? Shouldn't the dev team have some kind of influence on the >> > release schedule? Let me throw my favorite Stones song in here: >> > >> > "You can't always get what you want. But if you try sometimes, you can >> > get what you need" - And that's what we should do, imho! >> > >> >> In a month's time: >> >> >> >> * will SoaS be able to boot 30 netbook models in a matrix with >> >> functioning wireless, webcams, etc.? >> > >> > It will work on the same stuff that Fedora works on. And Fedora isn't >> > known to be especially buggy, from what I know. It's 'cutting-edge', >> > yes. >> > >> > Concerning the support of non-ordinary hardware: I hope people are well >> > aware of what it means to support more than Fedora does. It means that >> > we'll not only have to deal with Sugar issues (and upstream Fedora >> > ones), but also with issues, which occur due to the additional (and >> > probably patent encumbered) drivers and software. Who's going to support >> > that? >> > >> >> * on Intel Macs? >> > >> > Let me put it this way: We're releasing a version 1. We can define what >> > are the supported use-cases and what not. We can say "please use and >> > install VirtualBox on your Mac if you want to try it". >> > >> > I don't have a Mac here. I can't test it directly. Get me a Mac, and I >> > can try. Now seriously: When building images, I can only *guess* how >> > they behave on other platforms. That means that I'm still trying to >> > provide the best experience for all platforms. But I can't do >> > everything. If somebody wants to have it really working on a Mac, he or >> > she must work on it. I see all these tickets, but I can't really do >> > anything against it. And that's a little bit frustrating. >> > >> >> * on XO-1s? >> > >> > Isn't this the goal of the fedora-xo / rawhide-xo effort (to which I've >> > been continuously contributing the kickstart files)? I've asked several >> > times about the relationship of SoaS and OLPC's next software release. >> > >> > My assumption was: We're going to have a SoaS live image, which includes >> > all drivers and the Sugar desktop. It could be still be installed on the >> > XO, but wouldn't be that optimized. >> > >> > On the other hand, people could grab the latest OLPC 1.5 release, which >> > included the same Sugar version, but with more modifications for the XO >> > and less bloat (e.g. unneeded drivers). >> > >> > Please, please tell me if I'm wrong! >> > >> >> * will it work flawlessly with a school server? >> > >> > Has anybody tried to get that working? I saw some posts here and there, >> > but I'm really not sure. When I asked for the feature request for the >> > RC, nobody stepped up mentioning this. And to add such a feature from a >> > RC to a Final version is - imo - a little bit too much. Wouldn't it make >> > sense to push this to SoaS for Sugar 0.86? >> > >> >> * will adding/updating Activities be straightforward and easy? >> > >> > If somebody fixes the sugar-update-control (I've had this listed as an >> > urgent ticket for quite some time!), yes. If not, still through a.sl.o! >> > >> >> * will we have a reliable stick loading tool? We certainly don't now, >> >> I have to cycle power on my Windows machines after loading each stick >> >> and there is no solution for OSX. >> > >> > True. Work in progess, I'd say. liveusb-creator and livecd-iso-to-disk >> > are our best guess; I heard that Luke was also working on something. >> > >> >> I'm afraid I don't see any advantages in moving up the v1 release >> >> date... but great risks if we rush to release a buggy SoaS. We will >> >> only create problems for ourselves. >> > >> > I've heard this argument for the beta release. And the beta release went >> > rather fine. There were no bigger issues for the supported use cases, >> > from what I've heard. And let me point out again: >> > >> > * the advantage of having a stable Fedora and a stable Sugar version >> > together >> > >> > * the advantage of gaining a lot of testers over summer break >> > >> > * the advantage of not loosing another month or two, in which things are >> > probably not going improve significantly >> > >> >> I've been working on big-splash marketing plans in the fall for some >> >> time now, but in a month I won't be able to do much more than a press >> >> release in time for LinuxTag (the current plan). >> >> >> >> My point of view is that a push to make SoaS bulletproof will be well >> >> worth the effort - we will have teacher buy-in and word-of-mouth, >> >> education blogs etc. will build our credibility (and supply >> >> much-needed feedback). >> >> >> >> I have grave reservations about how bulletproof SoaS can be in a >> >> month. Shouldn't a decision like this be made by weighing all the >> >> variables? >> > >> > The same reservations which came up right before the beta release? I'm >> > pushing this discussion (or better: decision?) NOW, as I was really >> > unhappy with how it all turned out for the beta release. We continued to >> > compose images updating our beta image because people wanted to have >> > this or that last minute change. And this is not going to happen again, >> > which is, why I'm continuing to remind people of the deadlines on the >> > wiki. >> > >> > If we want to include all the features in our very first release (like >> > online backup, school server connection, booting on all machines, and so >> > on) we'll never get a final release! Unless you employ some developers, >> > I suppose. Because I can't fight everywhere. >> > >> >> thanks >> >> >> >> Sean >> > >> > Cheers, >> > --Sebastian >> > >> > (who needs to run for gym in half an hour, but should be back in three >> > hours) >> > >> >> On Tue, May 26, 2009 at 2:16 PM, Sebastian Dziallas<<a href="mailto:sebastian@when.com">sebastian@when.com</a>> >> >> wrote: >> >>> >> >>> Hi everybody, >> >>> >> >>> please read this carefully, as it concerns major schedule changes >> >>> regarding our upcoming Sugar on a Stick release in the end of June. >> >>> >> >>> The original plan was have a Release Candidate based on F11 Final and >> >>> Sugar 0.84 at that time and a Final Version later in Q3. After serious >> >>> consideration, it looks way more sensible to do the following: >> >>> >> >>> => Omit the RC release and replace it with our Final Release! >> >>> >> >>> This means that Sugar on a Stick is going be released in June, on >> >>> 2009-06-24. Now, why? Well, there were quite some reasons: >> >>> >> >>> * Fedora 11 will be released on June 2 and Sugar 0.84 has already had >> >>> it's release some time ago. By moving our final release later into the >> >>> year, we'd be either forced to use some outdated or unstable >> >>> components, >> >>> as the next major Sugar version will be 0.86, which is targeted for >> >>> Fedora 12. We're preventing this by having our release now just a >> >>> month >> >>> after F11's. >> >>> >> >>> * It helps us a lot to get feedback from students over the summer >> >>> break, >> >>> so that we're increasing the likelihood of gaining more users. >> >>> >> >>> * Sugar on a Stick is rather stable right now - I'll outline this in a >> >>> separate e-mail! >> >>> >> >>> The updated roadmap is located here: >> >>> <a href="http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap" target="_blank">http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap</a> >> >>> >> >>> Package Maintainers will receive reminders to update their RPM >> >>> packages >> >>> soonish! Again, please make sure to follow the deadlines. The last >> >>> date >> >>> for changes is 2009-06-10. Afterwards, dev team's approval is >> >>> required. >> >>> >> >>> Please contact me with any concerns you may have - also off-list, if >> >>> needed! >> >>> >> >>> Best Regards, >> >>> --Sebastian Dziallas >> >>> _______________________________________________ >> >>> IAEP -- It's An Education Project (not a laptop project!) >> >>> <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a> >> >>> <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a> >> > >> > > > > > -- > Caroline Meeks > Solution Grove > Caroline@SolutionGrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a> </div></div> _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a> </blockquote></div> -- Caroline Meeks Solution Grove Caroline@SolutionGrove.com 617-500-3488 - Office 505-213-3268 - Fax