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-de...@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
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
