[IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar

[Gary C Martin]

Hi Bernie,

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  
>> friend,
>> 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  
> these
> "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.

Regards,
--Gary

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  
maintainers).

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.