Hi all!
There is a private email thread about how distribution might be
organized within the heterogeneous systems that can be potentially used
for Sugar installations. The background is, how such distribution should
be formed. In my mind, such system is doomed to be based on community
oriented solutions. So, I decided to share my thoughts publicly
to discuss them.
The system described below, should be finally implemented in Peru pilot
[1] program (for sure, it will take several years and will start with
pretty basic solutions). But, it shouldn't be treated as a local,
for Peru, solution. It is a pilot for harmonic system to share various
types of content (including activities) within the Sugar community.
It will be useful to clearly separate the content to provide:
(1) System components
Highly depends on hardware, packages that are provided, mostly,
by someone else, i.e., upstream.
(2) Sucrose
Sugar itself and the minimal startup kit of activities to start
exploring the rest of accessible content
(3) Favorited activities and content
The majority of activities and content that people in the field
will use. They are, at least, filtered by people (not upstream
creators) who stamped them as stable and good, from edu pov, to
start using as-is.
(4) Universe activities and content
The rest of content in the community. Might be new versions of
(3) that are not yet favorited, new activities that might be
included to (3), various kinds of experiments that, most likely,
will not be included to (3).
Common solutions:
* (1) is entirely from upstream; GNU/Linux official repositories with
system packages for regular desktops and system package (not sugar)
for XO laptops from OLPC (as a hardware provider, not software);
repositories should be LTS, systems in the field can't be updated too
often
* (2) is formed as singular project on OBS[2] (not OBS project per
usecase) for every supported (for a long time, i.e., LTS as well)
Sugar release; this OBS project is being built into a bunch of
repositories with packages, basing on needs in the field, bunch of
distros and arches; in other words, all people in the field,
regardless their platform, use the same packages (but built for
different platforms); in other words, something like
Sweets Distribution[3]
* (4) is basing on Sugar Network[4], as universal system for sharing
various types of content that assumes not only online environments
(not all users in the field have decent Internet connection);
content creators, upload their creatures (activities, articles, books,
etc) into Sugar Network; all these majority of content is accessible
for all Sugar Network participants; more over, Sugar Network covers
the full life cycle for this content: support for activities, feedback
from users, sharing ideas/problems/opinions, sharing Journal objects
created within uploaded activities, etc;
* the previous point will make situation really messy; for that reason,
(3) will take place; Sugar Network editors might pickup some content
to make sure its quality is good enough for as-is usage; editing might
be organized on several levels, i.e., particular deployment might
deicide to apply some post-filters to the global Sugar Network
content; such filtering might various from leaving it as-is to white
and black lists;
Some details:
* (3) might occur not only in "passive" mode by staring some content,
but also with:
* reuse Sugar Network collaborative features to work with upstream
creators to improve the quality
* upload to Sugar Network improved versions of the content and make it
favorited (if upstream is irresponsive)
* (4) with Sugar Network will cover Activity Library (ASLO) features;
it was made with intension, ASLO is limited in cases like:
* no decent support for binary activities
* no way to upload Journal objects created by activities
* bad integration with Sugar Learning Environment (people need to open
browse and login/register)
* no way to support people's experiments, it handles only singular
activity from original authors
using Sugar Network doesn't exclude ASLO, the only thing, the focus
should be switched form "mirroring ASLO on Sugar Network" to
"mirroring Sugar Network on ASLO"
* for activities, (4) means that users having (1) and (2), can start
"some Sugar Network client", findout on of (3) or (4) activities and
click it to launch; in 100% for (3) and sometimes for (4), system will
downlad prebuilt binaries, on OBS, to launch on client side; some times,
for (4), will be downloaded sources to built on client side
[1] http://wiki.sugarlabs.org/go/Deployment_Team/Peru/Puno
[2] http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System
[3] http://wiki.sugarlabs.org/go/Community/Distributions/Sweets_Distribution
[4] http://wiki.sugarlabs.org/go/Sugar_Network
--
Aleksey