[IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar
Gary C Martin
gary at garycmartin.com
Wed Sep 23 16:11:16 EDT 2009
On 23 Sep 2009, at 17:19, Bernie Innocenti wrote:
> El Tue, 22-09-2009 a las 16:51 +0100, Gary C Martin escribió:
>> This is not a "what if" it works right now and since 0.84. Any .xo
>> bundle in your Journal can be 'sent to' over the either to any
>> where by Journal will automatically install it for them. I have sent
>> the Physics.xo bundle to a number of remote folks via this method
>> (followed by sending example physics simulations). If you take into
>> account sneaker net, you've always been able to pop a .xo on a USB
>> stick and hand it to someone else. This is a reason I'd be happy to
>> see all .xo bundles appear in the Journal (so they can be shared, or
>> hacked on by our users).
>> Lets not loose one of the major open source benefits of Sugar, that
>> the commercial competition really can't provide.
> Sure. You make it sound like I said "let's drop the activity sharing
> feature, when in fact I was talking about esoteric scenarios, such
> as a
> user of i386-fedora10-sugar0.84 who wants to share a *binary* activity
> bundle with another user running armel-squeeze-sugar0.86.
Would that not potentially be covered if ActivityTeam agree a set of
supported platforms (and agree a 'fat' bundle)? We can _never_ test
and QA every platform in existence, so we have to at least agree on a
core N amount of 'stuff we will actually test', and modify N as those
core user platform needs change over time? New platforms will need to
use new Sugar releases.
> The use cases that work now would continue to work with any package
> format. Those that do not work now, would at least fail gracefully.
> In a distant future, we could even come up with good fallbacks for
> "what if" scenarios. But I wouldn't recommend complicating the design
> *for* them.
I say again :-( This is not a distant future, I see this as a core
benefit of current Sugar to educators and learners since Sugar was
released – though you can argue not many have (visibly) leveraged this
fantastic software feature – but that's just an education issue ;-)
I would dearly love to see only core Sugar components falling in the
'needs distro packaging' camp. And then all additional Activities as
non binary including source scripts. The process would then be about
agreeing the binary dependancies for sucrose at each major Sugar
release, and then requiring the minimum sucrose release needed when
trying to install a new .xo bundle.
P.S. these threads really depress me, why am I not working on
Labyrinth, Moon, Physics, et al, testing and QA'ing Sugar builds,
instead of trying to read this thread and argue (no offence intended
to Bernie, he's a great guy we would horribly, horribly struggle to
get along without). I can see me picking up N Sugar activities for
maintenance and then just releasing them in a way I think would be
best for our users (rather than professional developers or distro
P.P.S as a mac head I have no idea what to do with random distro
packages, but am quite happy renaming .xo as .zip and then picking
through the content on my platform of choice for review/reuse (quite a
frequent process for me at least). All of my dev/visual work is done
on a mac, I just make sure I test it all on an XO sugar install and/or
a Fedora Sugar vm before release so I'm not pushing garbage.
More information about the IAEP