[Pkg-sugar-devel] Why track activity version numbers?

Fri Apr 21 23:47:29 UTC 2017

Hi, Jonas

Thanks for the information about how to install the debian 'sucrose'. I 
need to give that a try.

Consider this example:

   author: Sugar coders (and GNU coders, Linux coders, etc.)
   publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
   maintainer: James Cameron (and Redhat maintainers, etc.)
   distro: OLPC
   deployer: OLE Nepal team
   admin: Parents, friends and siblings of children at Tundikhel
   user: Children at Tundikhel

My guess is that in this case there is no admin. Generally OLE Nepal 
sends a team to the site to do the deployment.

James Cameron describes Sugar on the XO as the OLPC OS. These are 
released by him on www.laptop.org. The current OLPC OS is 13.2.8. 
Generally, there is no maintenance. The changes come in new releases. 
Fortunately, the system is mature enough that there are no critical bugs 
that prevent use of the system.
Also, in most deployments such as those by OLE Nepal, there is no 
internet access so many security concerns are moot.

So the above should probably be:

author: members of the Sugar and open source community
publisher: www.laptop.org (James Cameron)
maintainer: none in the sense you describe (note activities are 
independent of the system and are released to ASLO asynchronously).
distro: de facto www.laptop.org (OLPC) but should be Sugar Labs (debian, 
Ubuntu, Raspbian, etc.)
deployer: OLE Nepal team
user: children and teachers

My real concern is that the Sugar desktop as installed have an 
identifiable version number (in Sugar it is shown in 'About My Computer' 
in 'MySettings').
Version 0.110 of Sugar should be the same in all distros of Sugar. The 
name sucrose is confusing and appears for historical reasons no longer 
applicable,

"I understand how admins and users perceive everything upstream as "an integral part of Sugar"

Actually admins and users accept the installation of Sugar on their 
client as Sugar. Because such a limited number of users have access to 
the internet, ASLO is essentially unknown.

This problem is the Sugar developers. Some see the activities 
incorporated by James Cameron in the OLPC OS versions as integral 
(although that lists varies by Xo model). Even the list of 
'non-erasable' activities is somewhat arbitrary. For example, the Chat 
activity is included but TurtleBlocks is not.

So from a Debian perspective as distro of the Sugar desktop, making a 
canonical version available for even numbered releases of Sugar (0.110 
-> 0.112) should be the pattern. The desktop should include as 
activities Browse, Write, Chat, Log, Terminal, Record, Jukebox, and 
Image Viewer. Record is a problem because it provides the interface to 
the host's camera and microphone. Other activities can be made available 
by Sugar Labs (as distro) via ASLO for installation by users and admins.

Naturally, I am speaking only for myself.

Tony

On 04/21/2017 07:53 PM, Jonas Smedegaard wrote:
> Quoting Tony Anderson (2017-04-21 09:12:29)
>> My questions are from a Sugar perspective.
> I believe it helps this conversation to distinguish between the
> following perspectives, listed in order of appearance:
>
>   author: Those authoring single components
>   publisher: Those releasing canonical versions of components
>   maintainer: Those adapting components to fit a system
>   distro: Those releasing canonical versions of a system
>   deployer: Those mass-installing a system onto many computers
>   admin: Those (reinstalling or) adapting an installed system
>   user: Those picking a color for their avatar and exploring Sugar
>
> In Debian, we call anyone "above" yourself as "upstream", and anyone
> "below" yourself as downstream.
>
> Here's an example inspired by recent OLPC blog entry:
>
>    author: Sugar coders (and GNU coders, Linux coders, etc.)
>    publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
>    maintainer: James Cameron (and Redhat maintainers, etc.)
>    distro: OLPC
>    deployer: OLE Nepal team
>    admin: Parents, friends and siblings of children at Tundikhel
>    user: Children at Tundikhel
>
>
> Here's an example taken out of thin air:
>
>    author: Sugar coders (and GNU coders, Linux coders, etc.)
>    publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
>    maintainer: SoaS hackers (and Redhat maintainers, etc.)
>    distro: SoaS
>    deployer: none (not mass-installed)
>    admin: An enthusiastic math teacher at some US school
>    user: Students at some US school
>
>
> Here's an example depicting a near-future dream:
>
>    author: Sugar coders (and GNU coders, Linux coders, etc.)
>    publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
>    maintainer: James, Sebastian, me (and fellow Debian maintainers)
>    distro: Debian
>    deployer: Somos Azúcar
>    admin: An enthusiastic math teacher at some peruvian school
>    user: Students at some peruvian school
>
>
> Note how from Sugar _author_ and _publisher_ perspective you need not
> care about Debian version numbers at all: The versioning of officially
> released Sugar activities is kept (and extended) by Debian packages.
>
>
>> The Browse activity is one of the 'non-erasable' activities which can
>> be considered an integral part of Sugar. As I understand pristine - it
>> is part of an update-system within Sugar, which in our context i
>> consider superfluous.
> I understand how admins and users perceive everything upstream as "an
> integral part of Sugar
> " - but here, discussing integration of Sugar and
> other parts, we *must* distinguish between the various upstream parts.
>
> In Debian context, a (graphical) system consists of kernel, services,
> console tools, GUI desktop and GUI applications.  In this context, Sugar
> is GUI desktop and GUI applications. Yes I know, Sugar *experience* is
> void of office connotations, but technical term is nevertheless desktop.
>
> Systems generally provide separate "user" and "admin" roles, and Sugar
> supports this in what you describe as activities being "non-erasable".
>
> Debian (and most other conventional distribution) further distinguishes
> between distro-controlled and locally controlled "non-erasable" parts:
> Distro-controlled parts gets updated when the distribution is updated.
>
> Some systems (possibly including SoaS) essentially _removes_ the admin
> role: System cannot be updated or customized, only used as-is.
>
> Browse being "non-erasable" is a distro/deployer/admin decision, not a
> Sugar concept.
>
> Browser is an activity like any other - but provides a core features,
> including the ability for the learner to get additional activities
> independent of the admin or other upstreams. Therefore distributions
> commonly includes that activity by default - but with Debian the admin
> can choose to not install Browse - either to deliberately provide the
> learner with a limited Sugar environment, or perhaps to force use some
> _alternative_ web browsing activity added locally.
>
> Browse also - even when non-erasable - is not immutable: The learner can
> choose to install Browse, effectively shadowing the non-erasable one
> with their version of choice (newer or older). When removing that
> $HOME-installed versioned again later, the system-provided version of
> Browse will reappear.
>
>
>> Normally, a school does not change software levels during a school
>> year. If the software gets corrupted, it is re-installed.
> Schools will avoid changing _features_, but should apply _bugfixes_.
> Debian distinguishes between feature changes and bugfixes, and provides
> upgrade channels strictly containing the latter - no matter if upstreams
> of Debian have same distinctions.
>
> Feel free to consider such ability to fix bugs as "superfluous". I
> wouldn't recommend that, however.
>
>
>> Anyway activities are number incrementally beginning with 1. Some have
>> tried to use this system with dates:
>>
>> such as version 20170412 or with decimal steps 158.2 and so on.
> Seems you are talking about Sugar _development_ constraints.  They don't
> apply to Debian, and it would not make sense to apply them to Debian.
> How to distinguish these?:
>
>   * Browse 45 packaged for Debian 7
>   * Browse 45 packaged for Debian 7, with bugfix 4 and 6 applied
>   * Browse 45 packaged for Debian 8
>   * Browse 45 packaged for Debian 8, with bugfix 4, 5 and 6 applied
>   * Browse 45¾ packaged for Debian 9, adapted to Ubuntu Yoghurt
>
>
>> So my concern was triggered by two things: an apparent 8 digit version
>> number and a blockage because of the pristine system affecting Browse
>> update.
> A Debian stable release do not block updates to Browse (but possibly a
> newer Browse may depend on functionality not available in older Debian)
>
> If your concerns are only Sugar author/publisher/user perspectives, then
> please _totally_ ignore details of Debian versioning and blockage:
> Debian versions and Debian blockage is part of _development_ of Debian.
>
>
>> My question for you is, is there a way to install the debian sugar via
>> dpkg, for example? Currently I am using the Ubuntu 16.04 version which
>> is obsolete and is tied to Ubuntu releases (the current version of
>> Sugar 0.110 requires installing Ubuntu 17.04).
> Yes, the official and supported-by-Deban way to install Debian-packaged
> Sugar onto a _Debian_ system is by use of dpkg.
>
> Normally dpkg is not used directly, however, but triggered by
> APT.  There are many ways to use APT - For single simple tasks I
> recommend the command-line tool "apt", and for more complex interactions
> (like "install those 3 packages, but suppress those 4 recommendations,
> and by the way also include that extra suggestions") I recommend to run
> the command-line tool "aptitude" in fullscreen mode (i.e. start it
> _without_ passing any package names at first).
>
> This command installs Debian-packaged sugar on a _Debian_ system:
>
>    apt install sucrose
>
> If you try any of above on Ubuntu or some other derivative of Debian,
> then feel free to tell on this list that your other system is broken,
> but tell them (not us) to fix it.
>
>
>   - Jonas
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-sugar-devel/attachments/20170422/291c39a6/attachment.html>