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

Aleksey Lim alsroot at member.fsf.org
Tue Nov 24 09:18:29 EST 2009

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)

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


More information about the Sugar-devel mailing list