[IAEP] Common Sugar distribution package contents.

[Tomeu Vizoso]

On Thu, Dec 4, 2008 at 9:53 AM, Morgan Collett <morgan.collett at gmail.com> wrote:
> On Wed, Dec 3, 2008 at 19:15, Jonas Smedegaard <dr at jones.dk> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Wed, Dec 03, 2008 at 08:36:42AM -0800, C.W. Holeman II wrote:
>>>http://sugarlabs.org/go/Sugar_Application_Stack:
>>>
>>>    *  Library Collections (e.g., for the Browse Activity)
>>>    * Sugar Activities (Browse, Read, Write, Record Turtle Art)
>>>    * Sugar
>>>    * Operating System (Linux, MacOSX, MSWindows)
>>>    * Hardware Platform ( XO-1,   EEE PC, Classmate,  XO-2)
>>>
>>>Libraries are distributed in collections.
>>>Activities are distributed in bundles.
>>>Sugar is distributed in various kinds of packaging.
>>>
>>>The library collections and activity bundle formats for Sugar are
>>>in a format that is common across all OS/Hardware platforms.
>>>Sugar is distributed in formats that depend upon the
>>>OS/Hardware platform.
>>>
>>>The contents of activity bundle like Turtle Art or Browse is the same
>>>across all OS/Hardware platforms.
>>>
>>>The performance of Sugar on various OS/Hardware platforms varies. This
>>>should only be for issues that are dependent upon the underlying
>>>hardware and OS. It should not be the case for Sugar, Activities and
>>>libraries. There should be a common or core set of Activities and
>>>Library Collections that are in every Sugar distribution regardless of
>>>the kind of packaging the OS uses.
>>>
>>>There should be documentation on what the common or core Sugar must
>>>always contain. The packagers need this information. There may be
>>>additional optional packages also defined that are intended to work on
>>>all systems.
>>>
>>>This is needed to promote Sugar as a friendly environment for outsiders
>>>to become insiders.
>>
>> Suggestion: Encourage, but do not mandate, distributions to follow the
>> Glucose/Fructose grouping of packages as documented at
>> http://sugarlabs.org/go/DevelopmentTeam/Source_Code and ecourage (not
>> mandate) releasing one of the following (prioritized - first is best):
>
> Sure, the whole point behind Glucose/Fructose is to have a collection
> of releases that are done together, tested to work together, and easy
> to package because the tarballs are all in a known location.
>
>>   1) All branches (0.81, 0.82 and 0.83 currently)
>>   2) All stable branches (0.82 currently)
>>   3) Only latest stable branch (0.82 currently)
>>
>>
>> This is releated to the recent discussion on whether Sugarlabs would
>> rather that Debian-edu) rip out and avoid Sugar from its next release
>> than release with software not matching latest stable branch.
>
> It is purely a recommendation, based on the presumed support issues.
> Sugar Labs is basically a community, more than it is an organisation.
> The community was asked, and the community responded.
>
> If the likely answer to every "problem" with the debian sugar packages
> is "oh, you're using an old unsupported unstable development version
> of Sugar, upgrade to 0.82" then is there any point in shipping 0.81?
> Will anybody actually use the 0.81 packages for a deployment? It's
> your call.
>
>> Must all parts of Glucose/Fructose be included in a distribution?
>>
>> Must all parts of Glucose/Fructose be installed together?
>>
>> Must all parts of Glucose/Fructose be no older than official release?
>>
>> Must all parts of Glucose/Fructose be no newer than official release?
>
> There are no rules. The answer to these questions is obviously "no".
>
>> What if a distribution does not obey your wish? Do you want to protect
>> your name like Mozilla does (leading to Debian renaming its web browser
>> to "Iceweasel" to be allowed to independently apply security patches)?
>> Or do you perhaps want to only protect your own official binary releases
>> like [Scratch]?
>
> As I said, it's purely a recommendation. Feel free to distribute what
> you want - but the first place the "users" come for support is (in my
> experience) the Sugar community, who is likely to say "for optimal
> experience, make sure you run the latest stable version".

I agree with this, in this moment. But I can see a not-so-far future
where user support for Sugar will be given mainly by local
communities, so we can better respond to different languages, cultures
and specifics of Sugar as deployed in one geographical area. And that
will certainly include different versions of Sugar running in
different versions (and derivatives) of distros.

Global organizations like SugarLabs and Debian will work so those
local groups have a quality platform on which to base their products,
but user support will be mainly given by local groups.

But for now, it's certainly how Morgan said.

Regards,

Tomeu