[SoaS] Sugar Creation Kit review for inclusion in SoaS

[Peter Robinson]

Thomas,

I'm going to add further to this but read this email. Point 3 is the
major point. Daniel Drake has been involved in more deployments than I
think everyone else combined so is I believe the BEST person to make a
judgement.

http://lists.sugarlabs.org/archive/iaep/2010-May/010956.html

> Thanks for your input. I am somewhat at a loss on how to proceed.
>
> *Maybe request Project status, like sugarlabs has granted sdz soas project,
> for the SDK DVD/CD sets.
> (this would not get fedora involved directly in supporting it.)

No it wouldn't but your missing some of my points. I will back fill.

> *I would volunteer to attempt to keep them current. Is there not a delta
> function to update only the changed portions of a file?

Yes, but that's a very large engineering issue.

> *I have some ideas/possible answers to your concerns, listed below, on how
> to possibly make the SDK a Soas "feature"

I want to make parts of it a "feature", parts of the things it is
trying to address are already planned to be fixed in SoaS v4.

> * The other Feature request  of a custom Browse screen for Soas may
> achieve similar results for connected users.

Agreed.

> http://wiki.sugarlabs.org/go/Features/Revised_Browse_default-bookmarks.html
>
> Cordially;
>
> Tom Gilliard
> satellit
>
> Peter Robinson wrote:
>>
>> Hi Thomas,
>>
>> My initial reaction is "Wow, what a lot of good stuff"! There's a lot
>> of stuff in here that is a feature in and of itself but (and there's
>> always a but) I feel the SCK as it stands won't become a 'Feature' of
>> SoaS. I'll make some bullet points below of my concerns and flesh the
>> data below.
>>
>> * It includes 5 copies of SoaS and related derivatives.
>> * It includes 140 Activities
>> * It includes a lot of manual work
>> * Its MASSIVE! I've seen sizes ranging from 3.2 to 9Gb! We could fit
>> like 18 versions of the existing SoaSv3 into that!
>> * included documentation
>>
>> So the fleshing out bit:
>> * 5 copies?
>> - If we need to ship 5 copies of SoaS we're doing something wrong.
>> - We don't ship old copies of SoaS in the latest version. Do you see
>> MS or Apple or Fedora doing that? No! Strawberry is no longer
>> supported, Blueberry is almost to that state. We don't have the
>> resources to deal with that and its a support nightmare. It also says
>> that we don't believe the latest version is the best.
>> - Size. People want one copy, to do that they don't want to download 5+
>>
>
> Do I want to make a V3 version only?
> * A CD is too small, unless there is a series of CD's with an Index
>   (maybe covering each directory on the CD)

So a v3 is basically just SoaS. What's the difference? In my opinion a
CD is too big still.

>> * 140 Activities
>> - No QA. The reason we cut down the Activities is Mirabelle was the
>> ability to provide well tested working Activities. The issue with Read
>> proves we had trouble dealing with 10. Doing that with 140+ isn't
>> sustainable.
>> - There's no guarantee of the license. We only want to ship free ones.
>> No flash. No Codecs etc.
>> - Binary inclusions. Support issues on the current SoaS release. It
>> causes problems and its hard to QA. See point above.
>> - Its out of date the moment you ship it
>>
>>
>
> *I can make a smaller subset of ASLOxo that covers Mirabelle Compatible
> Applications.
> http://people.sugarlabs.org/Tgillard/Activities-Index-Mirabell.ods
> was a first attempt at doing this.
> I have been editing the ASLO listings based on this testing.

So the smaller subset you make can then be reviewed and included in
SoaS after feature review and we're on the same page :-)

My points here are as follows but first see also Daniel's email quoted above:
- If there's to be activities included in SoaS they will be in SoaS
not as a separate tarball.
- We can't QA them all
- We don't want to include every bit of crap just for the sake of it.
We want a selection of good Activities that show case Sugar. We don't
want 20 memory games and 4 ebook readers. We want 1 of each that work
well.
- We are going to include more Activities in v4. Each one will go
through the Feature process and be accepted.

> *I think ASLO site has to be changed to recognize
> what version of sugar is requesting .xo downloads and not permit access to
> those not compatible.
> (restricted to password access -experimental)

But this won't work in a tarball full of Activities. Hence the reason
that we don't provide that and people can go to ASLO and get the extra
ones THEY want.

>> * Manual work.
>> - We need to automate as much as possible. Manual stuff has 3 main
>> issues. 1) error prone especially human 2) time consuming 3) QA.
>> - We want to automate more. Fedora has a feature called AutoQA. We
>> want to make use of stuff like this.
>>
>> * Its massive!
>> - While the idea is great it generally doesn't work
>> - DVDs are horrible and likely to break. This is even worse in the
>> developing world where the "Sneaker Net" still applies because the
>> conditions are worse. 9Gb keys are still expensive when your in the
>> developing world where wages are low.
>>
>
> * A series of CD's might cover this -sized for copying to 1-2 GB sticks (see
> above)

NO!! Its completely missing the point behind SoaS.

>> - It is out of date the moment you create it.
>> - Its large amounts of bandwidth, see 5 copies above.
>>
>> * Included documentation
>> - It is out of date the moment you create it.
>> - Its static and not dynamic.
>> - Its generally wrong and out of date
>>
>> So that sums up most of my concerns. The main concern is this though
>> "Its not one feature its a good dozen of them"
>>
>> Some of the issues that SCK was made to fix we plan to fix in v4, they
>> were know issues and done like that for a reason. In the rest of SCK
>> there's a lot of good stuff that should be individual features in and
>> of themselves.
>>
>> I hope that outlines some of my concerns and why as it stands I don't
>> believe the SCK can become a "Feature" of SoaS due to it being a super
>> set there of.

A couple of other points I meant to make in the original email.

Sugar on a Stick isn't designed to be ready and to contain all the
stuff required for a deployment. Its just not possible to contain what
a class from sub Saharan Africa, a Argentinian class of 6 year olds
and a class in Boston of 10 year olds will need. It is designed to
highlight the features such as collaboration for Teachers, Students
and as a test case for deployments. Deployments will _ALWAYS_
customise it to include what they need whether that be a sub section
of wikipedia in Spanish, or specific school related classroom
textbooks for Paraguay as a result of this there is no point in trying
to aim to fit every deployment as we will only miss the mark
completely.

As I mentioned in my previous mail there are a lot of good "Features"
in your proposal. What I need you to do is rather than submitting it
as "One big feature" is to break it down into a number of smaller
features so that each individual feature can be reviewed based on each
individual merit. You've already started this with the Bookmarks
feature we discussed last night.

The other thing you need to realise is that everything needs to be
contained 'within' the SoaS .iso. So by definition the SoaS .iso can't
be inside itself. That is a chicken and egg problem :-)

So a quick look through the list of stuff in your text file [1] I get
these features to give you an idea:
- Change to the default book marks in Browse
- Inclusion of local FLOSS manuals (pdfs)
- Increased selection of Activities (Feature for each)
- Alternate installation methods (Feature for each) - One note here is
that we need to keep it simple and we need a commitment for support.
- dejadup / duplicity inclusion
- Partition editor
- Text editor (what's wrong with Write BTW?)
- Inclusion of other References
- SugarClone

And with that list of features above we basically get SCK (yea, its
likely i've missed some but you get the point) so I'm not rejecting
SCK I'm asking you to break it down into bite size chunks (Features)
rather than expecting me to eat a cow in a single bite :-)

Peter