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

[Bernie Innocenti]

El Wed, 23-09-2009 a las 21:11 +0100, Gary C Martin escribió:
> 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.

That's a good idea, but if we lack centralized build tools (in the style
of most Linux distributions), how can we ever rebuild the bundles to add
support for a new platform to all existing activities?

Even if we did not care to have automated rebuilds, we can't expect
activity authors to build binaries for a bunch of different
architectures without providing them with a fully fledged clustered
build service such as:

 * Fedora's Koji; or
 * Ubuntu's PPA; or
 * OpenSUSE's Build Service
 * ...

By piggy-backing on native packages, we also get those for free.


> 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 appreciate the immense power of this fantastic idea.  I'm just looking
for ways to reconcile it with the difficulties of having to deal with a
large and fast-changing matrix of architectures and library
dependencies.

So far, it seems we're unable to put ourselves in a win-win situation
where users freely exchange *any* type of activity between *any* two
given machines running Sugar.

Something's gotta give, and we just do not seem to agree on which
features we drop and which we keep.

But we all definitely agree that we can't keep them all, right?

Because, presently, it looks like it's perfectly ok to sneak i386-only
binaries inside .xo bundles, without the accompanying source and
instructions to rebuild them for other architectures.

We've opened a Pandora's box with a thousand Pandora's boxes inside it.



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

Why, this is no longer the flame war we started from.  Now we've
switched to discussing an important technical issue that needed to be
discussed, soon or later.  Better soon than later.


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

Really?  Interesting.  Did you ever try to get your Sugar activities to
run on MacOS?  And what about the whole Sugar environment?

It would be an interesting project, and probably also useful to expand
Sugar's reach even more.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/