Re: [IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!
On Wed, May 27, 2009 at 08:51:47AM -0400, Caroline Meeks wrote: > Hi, > > I think one possible place where we are having a miss communication > is about what is "Sugar on a Stick" or SoaS. I agree with you about this. > I think to Sean and I it is a solution that can be used in schools. > [...] > > 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. > > [my impression of developers' impression is that they think the code > is ready to be called a "release"] I'd like to hear from some others but Sebastien thinks so. As do I (FWIW). > the full solution [is] 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. That's fine - I'd like to point out that doesn't mean the code isn't "releaseable". > 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? I don't know, but I think as you note: > 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. ...and thus "Sugar on a Stick" (insofar as it's physically manifest and can be "released") is a bunch of bits of Fedora Linux + Sugar Labs code/docs burnable on to a USB stick as well as Fedora Linux is able to do so. This, to me, is quite well named by the phrase "Sugar on a Stick". What you're talking about sounds, to use a similar nomenclature, as "School on a Stick" or "My own Pilot on a Stick" or even "Deployment on a Stick" (the first two already seem strained, and I think you'll agree the last is a bit much). So I think "Sugar on a Stick" is ready for release, as does its maintainer (Sebastien). It up to the decision-makers to move us forward on this. > Thanks, > Caroline Martin pgpVyStanMjMp.pgp Description: PGP signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!
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 On Wed, May 27, 2009 at 8:24 AM, David Farning wrote: > > 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 > Date: Tue, May 26, 2009 at 9:43 AM > Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! > To: Caroline Meeks > Cc: Sean DALY , Sebastian Dziallas > , Walter Bender , Tomeu > Vizoso , Bernie Innocenti , > Simon Schampijer , Greg Dekoenigsberg > > > > 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 > 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 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 ca
[IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!
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 Date: Tue, May 26, 2009 at 9:43 AM Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! To: Caroline Meeks Cc: Sean DALY , Sebastian Dziallas , Walter Bender , Tomeu Vizoso , Bernie Innocenti , Simon Schampijer , Greg Dekoenigsberg 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 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 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
[IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!
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 Date: Tue, May 26, 2009 at 9:43 AM Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! To: Caroline Meeks Cc: Sean DALY , Sebastian Dziallas , Walter Bender , Tomeu Vizoso , Bernie Innocenti , Simon Schampijer , Greg Dekoenigsberg 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 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 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
[IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!
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 Date: Tue, May 26, 2009 at 9:43 AM Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! To: Caroline Meeks Cc: Sean DALY , Sebastian Dziallas , Walter Bender , Tomeu Vizoso , Bernie Innocenti , Simon Schampijer , Greg Dekoenigsberg 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 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 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
[IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!
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 Date: Tue, May 26, 2009 at 9:43 AM Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read! To: Caroline Meeks Cc: Sean DALY , Sebastian Dziallas , Walter Bender , Tomeu Vizoso , Bernie Innocenti , Simon Schampijer , Greg Dekoenigsberg 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 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 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,
