Changes

'''Bazaar'''<br>

'''Bazaar'''<br>

In cases when Sugar is not packaged or there are no required dependencies, packages will be built on Bazaar. But the major purpose of Bazaar is to be a place to consolidate all Sugar doers' efforts:

In cases where Sugar is not packaged, or there are no required dependencies, packages will be built on Bazaar. But the major purpose of Bazaar is to be a place to consolidate all the efforts of Sugar doers:

* host released sources (so, there is no need in requesting a shell account to upload files to http://download.sugarlabs.org),

* hosting released sources (so, there is no need in requesting a shell account to upload files to http://download.sugarlabs.org),

* being a universal build farm for binary-based projects,

* being a universal build farm for binary-based projects,

* support QA workflows when Bazaar packages might be branched, tested, and released.

* supporting QA workflows where Bazaar packages might be branched, tested, and released.

'''Activity Library'''<br>

'''Activity Library'''<br>

=== Tools ===

=== Tools ===

To interact with doer environment from command line, only [[Platform Team/Guide/sweets command|sweets]] command is needed. See walk-through [[Platform_Team/Sugar_Doers_Kit#Start_from|tutorials]] for various use cases.

To interact with the doer environment from a command line, only the [[Platform Team/Guide/sweets command|sweets]] command is needed. See walk-through [[Platform_Team/Sugar_Doers_Kit#Start_from|tutorials]] for various use cases.

Involved technologies within doers environment:

Technologies involved within the doers environment:

* [http://0install.net 0install] the only package management system which is being used on high level.<br>In some meaning, ''0install + sweets and related infrastructure'' might look similar to ''rpm + yum and related infrastructure''.

* [http://0install.net 0install] - The only package management system that is being used ultimately.<br>In some sense, ''0install + sweets, and related infrastructure'' might look similar to ''rpm + yum, and related infrastructure''.

* [http://www.packagekit.org/ PackageKit] as a backend for 0install to work with native package management systems.

* [http://www.packagekit.org/ PackageKit] - Is used as a backend for 0install to work with native package management systems.

* [https://build.opensuse.org OBS] as the source for [[#Bazaar|Bazaar]].

* [https://build.opensuse.org OBS] - The source software for [[#Bazaar|Bazaar]].

* [https://addons.mozilla.org AMO] as the source for [[#Activity_Library|Activity Library]].

* [https://addons.mozilla.org AMO] - The source software for [[#Activity_Library|Activity Library]].

=== Software projects, sweets ===

=== Software projects, sweets ===

Software projects (not only Sugar related) are named ''sweets'' within doers environment and might be one of several types:

All software projects (not just the Sugar related ones) are designated ''sweets'' within the doers environment. ''sweets'' might be one of several types:

* aliases to native GNU/Linux packages that map the same sweet name to appropriate package name for particular GNU/Linux distribution (further, aliases),

* aliases to native GNU/Linux packages, which map the same sweet name to the appropriate package name for a particular GNU/Linux distribution (henceforth, aliases),

* recipe based, i.e., native for sugar environment, projects (further, sweets).

* recipe based, i.e., native to sugar environment, projects (henceforth, sweets).

==== [[Platform Team/Recipe Specification|Recipes]] ====

==== [[Platform Team/Recipe Specification|Recipes]] ====

This is the departing point for both, users and doers, environments for the particular sweet project. It is intended to accomplish the major task - how to prepare the code to launch.

This is the starting point for both users' and doers' environments for a particular sweet project. Its major task&mdash;specifying how to prepare the code to launch.

Sweets contain recipe file in sources directory. Recipes are improved versions of {{Code|activity.info}} files with the difference that recipes fully describe the sweet (i.e., like GNU/Linux distribution spec files do) and intended not only for activities.

Sweets contain a recipe file in the sources directory. Recipes are improved versions of {{Code|activity.info}} files with the difference that recipes fully describe the sweet (i.e., like GNU/Linux distribution spec files), and are intended not only for activities.

Recipes contain various metadata about the sweet, including important ones like version, dependencies and ''sweet_id''. The value of ''sweet_id'' is just a short (not unique) name which is being used in various sweet [[#Identifiers and implementations|identifiers]].

Recipes contain a variety of metadata about the sweet, including important things like version, dependencies, and ''sweet_id''. The value of a ''sweet_id'' is just a short (not unique) name, which is used in various sweet [[#Identifiers and implementations|identifiers]].

==== Identifiers and implementations ====

==== Identifiers and implementations ====

Where:

Where:

* ''bazaar-hostname'', [[#Bazaar|Bazaar]] instance which is being used to host projects

* ''bazaar-hostname'' - The [[#Bazaar|Bazaar]] instance that is being used to host projects.

* ''user-account'', account name of the developer on [[#Bazaar|Bazaar]]

* ''user-account'' - The account name of the developer on [[#Bazaar|Bazaar]].

* ''sweet_id'', sweet identifier from the project recipe

* ''sweet_id'' - The sweet identifier from the project recipe.

The same unique identifier might be associated with several sweet implementations from the same doer. Implementation is just a copy of the sweet in ready-to-use state, e.g., several versions of the sweet, several binary implementations of the same sweet version built against several environments. Only one implementation will be chosen in running environment basing on operating system, hardware architecture, GNU/Linux distribution or user preferences (like running only stable versions).

The same unique project identifier might be associated with several sweet implementations from the same doer. An implementation is just a copy of the sweet software in a ready-to-use state, e.g., several versions of the sweet, several binary implementations of the same sweet version built against several environments. Only one implementation will be chosen for a running environment, based on operating system, hardware architecture, GNU/Linux distribution, or user preferences (like running only stable versions).

The reason to have second type of sweet identifiers is collecting sweet implementations from several doers. For example, doer might tweak existed project and share it, other people will be aware of existence of another sweet implementations. The process of choosing the proper implementation to run will be extended by additional options like choosing implementations only from particular doer.

A second type of sweet identifier is used for collecting sweet implementations from several doers. For example, a doer might tweak an existing project, and share it, and want other people to be aware of its existence as another sweet implementation. The process of choosing the proper implementation to run will be extended by additional options, such as choosing implementations only from a particular doer.

==== Development implementations ====

==== Development implementations ====

Ready to use sweets implementations, i.e., locally available, might be in two states:

Ready-to-use sweets implementations, i.e., those locally available, might be in two states:

* read-only implementations that might be only used,

* read-only implementations, which can only be used,

* under development implementations that might be changed at anytime.

* under-development implementations, which might be changed at any time.

In other words, development implementations are just checked out sweets sources placed to one of default directories, by default {{Code|~/sweets}} and {{Code|~/Activities}}.

In other words, development implementations are just checked-out, sweets sources, placed in one of the default directories, {{Code|~/sweets}} and {{Code|~/Activities}}.

Development implementations have the highest running priority but it might be changed by user at any time since these are regular implementations.

Development implementations have the highest running priority, but that may be changed by the user at any time, just like regular implementations.

Such implementations is a good way for [http://en.wikipedia.org/wiki/Sneakernet sneakernet] sharing of sweets, just bundling sweet directory and extracting it on another machine is needed.

Such implementations are a good way for [http://en.wikipedia.org/wiki/Sneakernet sneakernet] sharing of sweets, by just bundling a sweet directory, and extracting it on another machine, as needed.

=== Sweets tracker ===

=== Sweets tracker ===

Sweets tracker is a DBus service that is being used by {{Code|sweets}} command and Sugar Shell to run sweets and handle other high-level sweets related procedures.

The Sweets tracker is a DBus service that is being used by the {{Code|sweets}} command and the Sugar Shell to run sweets, and handle other high-level sweets related procedures.

The reasons to have DBus service are:

The reasons for having a DBus service are these:

* need to monitor development implementations to not scan directories every time,

* the need to monitor development implementations and not to scan directories every time,

* cache 0install internal procedures to speed up launch process,

* to cache 0install internal procedures so to speed up the launch process,

* background updates,

* to enable background updates, and

* support [http://0install.net/0mirror.html mirroring] of 0install implementations to share already downloaded files within local network to decrease internet traffic.

* to support [http://0install.net/0mirror.html mirroring] of 0install implementations so to share already downloaded files within a local network to decrease Internet traffic.

=== [[Platform_Team/Bazaar|Bazaar]] ===

=== [[Platform_Team/Bazaar|Bazaar]] ===

Bazaar is a patched version of [https://build.opensuse.org/ OBS]. It handles all server-client share related procedures, like hosting sweet sources and implementation. For binary based sweets, Bazaar is a build farm as well.

Bazaar is a patched version of [https://build.opensuse.org/ OBS]. It handles all server-client share related procedures, like hosting sweet sources and implementations. For binary-based sweets, Bazaar is a build farm, as well.

In many cases Bazaar will be used implicitly:

In many cases, Bazaar will be used implicitly:

* uploading new version will be called from {{Code|sweets commit}} command,

* uploading a new version will be called from the {{Code|sweets commit}} command,

* launch will happen just by mentioning sweet url.

* launching will happen just by calling a sweet url.

The only thing is needed, being registered on Bazaar. For default http://bazaar.sugarlabs.org instance, being registered in [https://cas.sugarlabs.org/ Sugar Labs Central Login] system.

The only thing required is being registered on Bazaar. For the default http://bazaar.sugarlabs.org instance, that means being registered in the [https://cas.sugarlabs.org/ Sugar Labs Central Login] system.

=== [[Activity Library]] ===

=== [[Activity Library]] ===

In doers environment, Activity Library will be a catalog of sweets. It might be treated as a frontend of Sugar development, when [[#Bazaar|Bazaar]] is a backend and an analog of the current Developer Hub on Activity Library.

In the doers' environment, the Activity Library will be a catalog of sweets. It might be treated as a front-end for Sugar development, where [[#Bazaar|Bazaar]] is a back-end, and an analog of the current Developer Hub on Activity Library.

The only sweet URL is needed to add new Activity Library entity, the rest will be fetched from the sweet. Also [[#Bazaar|Bazaar]] might automatically publish information of newly created sweet implementations.

A sweet URL is all that is needed to obtain a new Activity Library entity; the rest will be fetched from the sweet at the other end of that URL. At some point, [[#Bazaar|Bazaar]] might automatically publish announcements of newly created sweet implementations.