On 28 Aug 2009, at 11:57, Tomeu Vizoso wrote: > On Fri, Aug 28, 2009 at 12:51, Peter Robinson<pbrobin...@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?
My vote would go to agreeing on N (where N is a very small number) architectures we want to support, and then having a 'fat' Activity bundle solution so that Activity Authors desperate/keen enough to use something binary, that is not provided by the Sugar Platform, are recommended to include a binary for each N architectures in their .xo bundle. Unsupported architectures are unsupported, until which time the community agrees to support a new architecture (i.e Nokia or Sharp offer to support us to make Sugar run well on there new glossy 10 inch multi touch wireless & 3G tablet aimed at educational markets, you know, the new wave that will hit in 6+ months once they start trying to play catch with Apple). No compiling, no yum'ing, no apt'ing. A simple hello_architecture activity and some Activity Team wiki notes would act as a template for authors. Perhaps we could fix up Paint/ Colours/Physics as other working examples. Regards, --Gary P.S. Think this is pretty close to some work already done by Aleksey. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel