[Sugar-devel] Fructose - What is it? What should it be?

[Gary C Martin]

Hi Tomeu,

On 26 Nov 2009, at 12:41, Tomeu Vizoso wrote:

> On Tue, Nov 24, 2009 at 17:44, Simon Schampijer <simon at 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?

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?

Regards,
--Gary