[somos-azucar] Harmonic Sugar distribuition

[Walter Bender]

On Thu, Mar 15, 2012 at 1:17 AM, Aleksey Lim <alsroot en sugarlabs.org> wrote:
> 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

Would the plan include using Sugar Network to eventually replace ASLO?
Then we could have a much more integrated workflow for building
databases of activity output around the activities
themselves--something I think would be of real utility to teachers and
learners.

regards.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org