[Sugar-devel] The sugar stack

[Aleksey Lim]

On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote:
> It seems time to think about the next _big_ technical issue for
> growing Sugar Labs.  Clearly articulating the Sugar Stack.  For the
> last year or so, we have been circling the issue with talk of stable
> APIs, Glucose, Fructose, and expected dependencies.
> 
> Last year, we created the release cycle.  At first, _everyone_
> disagreed with the idea; Release cycles are perfect for _no_one_.
> Defining the Sugar Stack is going to be nearly as painful, because the
> 'stack definition' is not going to be perfect for anyone.

yeah, but using 0install dependencies[1] should make stack definition
issue not so hard(we can include to stack only very common dependencies)

> Some reasons for defining a stack:
> 1. Statement of quality.  One of the most frequently cited reasons for
> the glucose, fructose, honey classification is quality.
> - Glucose is the core stuff.
> - Fructose is the supported stuff.
> - Honey is the rest.
> This is a very valid method of defining layers of the project; Fedora
> had core and extras, Ubuntu has main and universe, Eclipse has various
> levels of official-ness, (none of which I can remember) The kernel
> simply has 'in-tree' and 'out-of-tree'.
> 
> 2. Statement of synchronisation.  In some instances it is desirable
> for various parts of a project to be tested and release together.
> - Sugar core is developed according to a release cycle.
> - Fructose tends to align with the release cycle.
> - Honey happens 'when it happens.'
> This is also very valid; Distro all have synchronised releases.  The
> desktop managers all ship a core at distinct release points.  Ecplise
> has its release train.
> 
> 3. Statement of what is provided.  Down streams _need_ to know what
> applications they can depend on.
> - Core APIs
> - Optional things to meet dependencies.
> Most languages provide for core functionality which can be extended
> with modules.  Apache also is organized as http server and installable
> modules.
> 
> Many of the discussion about this have stalled because of confusion
> over what aspect the stack we are trying to define.
> 
>  As a starting point, I would suggest:
> 1. That we get rid of the glucose - fructose categorisation.  It is
> overloaded and confusing

yup, I like scheme when new activity developer well understands(from
beginning) that there is core and his new activity(w/o "core", since
fructose comes from sucrose release) which uses core functionality.

> 2. That Quality and synchronisation of activities becomes an
> Activities Team issue.

and ASLO could be useful on that way(featured activities, editors
collections etc) and this process is pretty transparent(e.g. we have
public aslo@ ml to discuss editros questions) and well visible(all
editors changes are accessible right after changes) on ASLO.

So, in comparing with fructose scheme(which e.g. involves all distro
packagers, since they should package fructose) in case of ASLO we
have more flexible method.

> This shifts the discussion back to the hard problem of how to think
> terms of 'Sugar-Space' and 'Activities-Space'.
> 
> Long term projects success depends on external organisation knowing
> what they can depend on to be part of Sugar.
> 
> Before starting a holy war....  The process of articulating the Sugar
> stack, much the the release cycle, is an evolutionary process.  There
> is no way the anyone could sit down and declare, 'This is what Sugar
> consists of... and will consist of in the future.'
> 
> Instead, the stack is a snapshot of agreed upon APIs, libraries, and
> applications on which downstream activities developers can depend.  I
> suggest that:
> 1. The development team and activities team work together to start
> defining the boundary between core and activities.

well, from tech POV, its pretty clear - there are core packages and
activities that use core API/services/resources

> 2. All changes to the core and activities boundary should go through
> the new features (or similar) process.
> 
> After a few iterations, this process will become as second nature as
> the release process.
> 
> david
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 

[1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Download_dependencies_for_sugar_activity

-- 
Aleksey