2009/11/27 Gary C Martin <g...@garycmartin.com>: > Hi Tomeu, > > On 26 Nov 2009, at 12:41, Tomeu Vizoso wrote: > >> On Tue, Nov 24, 2009 at 17:44, Simon Schampijer <si...@schampijer.de> wrote: >>> On 11/24/2009 03:18 PM, Aleksey Lim wrote: >>>> On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote: >>>>> Hi, >>>>> >>>>> this came up several times now. People where wondering what Fructose is. >>>>> From the definition it is: >>>>> >>>>> The Sugar developers will need some example set of activities with which >>>>> to demonstrate Sugar. This set is Fructose. The packages in Fructose >>>>> should be selected to make the resulting environment as impressive as >>>>> possible for a potential client or user. Packages should therefore be >>>>> stable, polished, and exercise the widest possible range of features. >>>>> Fructose may also serve as an example for people constructing their own >>>>> Activity sets. [1] >>>>> >>>>> The current list of activities can be found at [2]. >>>>> >>>>> The fructose activities follow the Sucrose development cycle (0.84, >>>>> 0.86...). This means they follow the freezes, provide source tarballs, >>>>> need a present maintainer etc. The duties are described at [3]. The >>>>> activity gets noted in release notes, possibly more attention by the >>>>> localization teams as revenue. >>>>> >>>>> In the end their are downsides and upsides to be part of Fructose. There >>>>> were some arguing, that only system dependent activities should be part >>>>> of it (e.g. Browse with the dependency on hulahop). >>>>> >>>>> There were some discussions that we would loose the show case activities >>>>> when an activity would not be part of Fructose anymore. This comes down >>>>> to packaging, as for rpm packaging one needs to provide the source >>>>> tarballs and need to follow certain rules. Some distributors may ship >>>>> the .xo bunles at one point, otherwise probably won't, so it is a good >>>>> habit to do the source releases. >>>>> >>>>> Anyhow, this is a bit of the background. Let's think how we can move >>>>> forward on this topic. We should do it quickly, to be able to keep the >>>>> work on 0.88 going. >>>> >>>> In my mind, the best thing we can do is making clear definition: >>>> >>>> 1) we have core with strong release cycle >>>> * glucose(and its dependencies) >>>> * sugar platform(additional dependencies) >>>> (core) >>>> >>>> 2) various sugar activities >>>> (the rest of development community) >>>> >>>> 3) sugar users >>>> (the rest of community) >>>> >>>> Relations between 1) and 2) totally depends on sugar release cycles. >>>> Activity developers decide what release cycles they can/should/will >>>> support. >>>> For activities like Browse it will several activities versions per SP >>>> release. Most activities will support several SP release. >>>> >>>> Relations between 2) and 3) is task for various deployment methods. >>>> Since fructose makes sense mostly for users, its content should totally >>>> depends on deployers not core. So I can't see the 4rd place for fructose, >>>> only as a part of 2). >>> >>> So far, I conclude, that Fructose as we have it today is outdated. The >>> tarball issue could be solved with adding for example a field to ASLO, >>> to be able to upload a tarball too, when doing a release. As I think >>> where to upload a tarball was one big issue back in the days. The >>> packaging (rpm, xo, deb) and how you install/upgrade, where you install >>> (system vs user space) is then up to the deployer. As the tarball is >>> available, that should work out nicely. >>> >>> Activities that rest coupled to the Sucrose release would be Browse and >>> Etoys as they have strong platform dependencies. >> >> I think hulahop is more mature now and won't change as much in the >> future. Also Python allows us to do lots of tricks to keep backwards >> compatibility, but it all takes time developing and testing. Browse >> may be now in the same situation as Read. >> >> I don't think the problem is that Browse depends too much in hulahop, >> but that the only help the maintainer has with regard to this issue is >> when people complaint that the last released Browse is not working in >> the release they are running. >> >> With some more manpower I think we could surmount these issues. > > Sorry, just to be sure I read correctly, were you recommending/suggesting > that we should try to update the Browse activity so that it works on past and > present versions of Sugar (let's say 0.82 and up) rather than forking > versions at every new Sugar release?
I was suggesting the possibility, but if it's a good idea or not should be decided by its maintainer with the participation of deployers, etc. > Does anything else need hulahop, or could it just be bundled inside Browse? I > know there was a lot of talk about creating a simple html widget for any > activity to easily use, but just wondered if anything else is actually using > hulahop now. Karma perhaps, the Help-french activity, Lucuan's Webified? Yeah, I think some activities ended up using it. There's also some downsides to bundle binaries inside .xos, specially if they depend on much other stuff in the system. Regards, Tomeu > Regards, > --Gary > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
