[IAEP] Common Sugar distribution package contents.

[Morgan Collett]

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".

>  - Jonas

Regards
Morgan