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

[Simon Schampijer]

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.

Of course, activity authors are encouraged to follow the Sucrose release 
cycle, the point is: they don't have to. As Walter stated there is some 
benefit. Keeps you focused etc.

More thoughts?
    Simon