[Sugar-devel] Harmonic Sugar distribuition
Walter Bender
walter.bender at gmail.com
Fri Mar 16 08:08:46 EDT 2012
On Thu, Mar 15, 2012 at 1:17 AM, Aleksey Lim <alsroot at 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
More information about the Sugar-devel
mailing list