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. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
