[IAEP] Fwd: [SoaS] Important Schedule Changes - Please Read!

[David Farning]

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 <dfarning at sugarlabs.org>
Date: Tue, May 26, 2009 at 9:43 AM
Subject: Re: [IAEP] [SoaS] Important Schedule Changes - Please Read!
To: Caroline Meeks <caroline at solutiongrove.com>
Cc: Sean DALY <sdaly.be at gmail.com>, Sebastian Dziallas
<sdz at sugarlabs.org>, Walter Bender <walter.bender at gmail.com>, Tomeu
Vizoso <tomeu at sugarlabs.org>, Bernie Innocenti <bernie at codewiz.org>,
Simon Schampijer <simon at schampijer.de>, Greg Dekoenigsberg
<gdk at redhat.com>


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
<caroline at solutiongrove.com> 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 <sdaly.be at gmail.com> 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
>> feedback at sugarlabs.org 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 on-disk.com, 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 <sebastian at when.com>
>> 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 <sebastian at when.com>
>> > Antwort an: Sebastian Dziallas <sdz at sugarlabs.org>
>> > An: Sean DALY <sdaly.be at gmail.com>
>> > CC: Walter Bender <walter.bender at gmail.com>,  Caroline Meeks
>> > <caroline at solutiongrove.com>, David Farning <dfarning at sugarlabs.org>,
>> > Tomeu
>> > Vizoso <tomeu at sugarlabs.org>, Bernie Innocenti <bernie at codewiz.org>,
>> >  Simon
>> > Schampijer <simon at schampijer.de>, Greg Dekoenigsberg <gdk at redhat.com>
>> >
>> > [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
>> >> (http://www.sugarlabs.org/press)... 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<sebastian at when.com>
>> >>  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:
>> >>> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap
>> >>>
>> >>> 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!)
>> >>> IAEP at lists.sugarlabs.org
>> >>> http://lists.sugarlabs.org/listinfo/iaep
>> >
>> >
>
>
>
> --
> Caroline Meeks
> Solution Grove
> Caroline at SolutionGrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
>