[IAEP] The sugar stack

[David Farning]

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.

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
2. That Quality and synchronisation of activities becomes an
Activities Team issue.

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