[Sugar-devel] The ARM is near

[Jonas Smedegaard]

On Fri, Aug 28, 2009 at 07:11:54AM -0400, Walter Bender wrote:
>On Fri, Aug 28, 2009 at 6:57 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
>> On Fri, Aug 28, 2009 at 12:51, Peter Robinson<pbrobinson at gmail.com> wrote:
>>>>>> As a developer, dropping .xo support would take a lot of work 
>>>>>> from my shoulders, but I suspect our users would kill us...
>>>>>
>>>>> I suspect users will kill you as well when activities don't work 
>>>>> on machine X but they do on Y....... your damned if you do, damned 
>>>>> if you don't. Either way there's going to be pain, whether its the 
>>>>> in the short or the long term.
>>>>
>>>> Yeah, I guess Jonas' suggestion of promoting platform independent 
>>>> bundles as "first class" addresses this concern.
>>>>
>>>> I personally don't think we are going to be able to outdo rpms nor 
>>>> debs so the less binary code we have the better.
>>>>
>>>> That said, our users are free to do whatever they want and Sugar 
>>>> will be deployed in wildly different scenarios. So I think that 
>>>> leaving some extra flexibility is wise because if we try to 
>>>> anticipate all the ways in which Sugar will be used, we'll fail.
>>>
>>> That's the advantage of open source - people can do what ever they 
>>> like. I think from the sugar perspective there needs to be some 
>>> standard defined and recommendation made +to make supporting it 
>>> easier rather than just sitting on the fence. Deployments or people 
>>> of course are then free to ignore those recommendations and package 
>>> half a binary distribution up in their .xo if they so choose. At the 
>>> moment its not so much of an issue but moving forward I think that 
>>> if something isn't well defined now we're going to end up with a 
>>> massive support burden going forward with users coming to mailing 
>>> lists complaining because activities don't work and that sugar is 
>>> bad because nothing works.
>>
>> I agree, what's the Activity Team's opinion on this?
>
>Wearing my lowly activity-developer hat, I am looking for guidance. I
>have stalled out on the maintenance of several activities (Turtle Art
>with Sensors and Measure) because I don't want to make unilateral
>(uniformed) decisions about how to handle the multi-arch issue. I
>await guidance from those with more packaging experience than me (just
>about anyone on this list).

Not quite sure what kind of guidance you ask for, but here's some random 
thoughts. I apologize ahead if they are hilariously obvious:


For each major Sugar release, document the provided ABIs offered for 1st 
class activities (i.e. arch-independent activities depending only on 
Fructose).

For each 1st class activity, decide on a minimum requirement - e.g. 
"needs Fructose 0.82 or newer".

Treat "funky things" requiring more than the bare minimum as optional. 
That is, make sure that the activity does not explode if the 
requirements are not met on the host system - e.g. hide that non-working 
funky feature from the menus.

Treat binary blobs outside of Fructose as "cheating".  That is, require 
official releases of 1st class activities to not contain arch-dependent 
binary blobs. Optionally promote as "dirty hacks" some alternatative, 
unofficial releases that also contain some binary blobs to make the 
activity work better on some specific system (i.e. a specific version of 
SoaS for a specific hardware platform).



Kind regards,

  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090828/fd45e238/attachment-0001.pgp