Difference between revisions of "Platform Team/Sugar Packaging Management System"

Revision as of 14:38, 26 April 2010

Purposes

Sugar is not unique when faced with questions like how to deploy new features to users. There are well-tested and robust models in the FOSS world when projects follow regular release schedules, e.g., 6-month, support, long-time supported releases, etc. But there could be cases when sugar has its specific needs:

The most broad sugar audience is teachers, students, schools and other educational organizations. Thus, we can not rely in all cases on the fact that all sugar users will use only the latest stable sugar release. For example, the latest OLPC sugar is 0.82, next will be 0.84, but the latest stable version is 0.88.

Many developers participate on a casual basis, thus, supporting several sugars (one for stable OLPC, one for next stable OLPC, and one for the latest stable upstream) for their activities is overkill. As such, people support only one branch, and either drop other user categories, or do not implement useful features from the latest sugar (like the new toolbar design).

One of original sugar purposes is stimulating people to hack existed code and share their code. Having (in ideal) such huge heap of code we can't rely on the fact that all these activities will work on a bunch of sugar releases. For example, if someone took Record activity (maybe not last version) and implemented new feature, he just wants to share his hack, not test this new code on several Sugar Platforms, ask QA to test it, ask ASLO editors to review etc., just share.

So, the right answer could be a more scalable and decentralized development model. That doesn't mean we should follow only a decentralized model, but we can effectively mix both—a centralized model with the core team and regular releases, and add an optional, decentralized model.

Implementation ideas

There could be two level solutions that are tied to each other.

Intermediate level libraries

A decentralized development model means here that the activity developers' focus is moved from core releases to releases of core libraries they use in activities. So, the corner stone idea is switching from monolithic sucrose + activities scheme to monolithic sucrose + intermediate level libraries + activities.

The major purposes in having intermediate level libraries are:

Support several sucrose release that are popular in deployments right now, so activity developers won't have to code bunch of ifs to support several sucrose releases, they just use what current intermediate libraries can provide and activity will work (or gracefully fallback) on all sugars in the field.
Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.

0install deployment mechanism

Intermediate level libraries will be especially useful if their recent versions could be installed on every sugar in the field in spite of the sucrose release on particular machine. 0install is obvious choice since it is (see Sugar Services to know more about 0install support in sugar):

Over GNU/Linux distribution mechanism
Could be install to user's home directory i.e. without having root privileges

Other, but not less, useful 0install feature is having several versions of the code in the same time. For example if activity can work only with particular version of some intermediate library, it will work with this exact version even if it is really old, of course this library version should be still supported.

Activity developers point of view

Having all mentioned above, activity developer needs only one thing to be sure that his activity will work on all sugars in the field - mention what intermediate libraries are needed and, maybe, what particular versions are. See Activity Developers Guide to know how it is implemented in 0sugar.

So, to support huge repository of doer's code (see 3rd point of purposes), there is no need in having huge QA to review every new piece of code, we just rely on activity coder that he mentioned all required libraries/versions (he can just type all versions he had during activity coding).

@@ Line 19: / Line 19: @@
 == Implementation ideas ==
-A decentralized development model means here that the activity developers' focus is moved from core releases to releases of services they use in activities.
+There could be two level solutions that are tied to each other.
-So, the corner stone idea is not having a monolithic sucrose. There could be several sucrose releases in the field, but with a bunch of services (i.e., packages) that have their own [[Documentation_Team/Services/Service_Developers_Guide#Versioning_scheme|API-based]] schedules and similar for other sugar dependencies, like sugargame or groupthink.
+=== Intermediate level libraries ===
-For glucose components, it could look like the following:
+A decentralized development model means here that the activity developers' focus is moved from core releases to releases of core libraries they use in activities. So, the corner stone idea is switching from ''monolithic sucrose'' + ''activities'' scheme to ''monolithic sucrose'' + ''intermediate level libraries'' + ''activities''.
-* Localized code that could be changed often to separate services with frequent releases.
+The major purposes in having intermediate level libraries are:
-* Keep the rest of the code in services with infrequent releases.
-* Use robust and explicit APIs for all services.
-For example, in the case of sugar-toolkit, it could be split:
+* Support several sucrose release that are popular in deployments right now, so activity developers won't have to code bunch of ifs to support several sucrose releases, they just use what current intermediate libraries can provide and activity will work (or gracefully fallback) on all sugars in the field.
+* Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.
-* Move all shell-related API to the shell itself to have one solid service - shell, and provide dbus API for all shell-related needs, e.g., getting information about the sugar environment.
+=== 0install deployment mechanism ===
-* Toolkit service, a list of widgets that use a stable API from shell service, and mostly are shell independent.
-* Move all datastore-related code to sugar-datastore - a datastore service.
-Services should be as independent as possible, e.g., activity developers could use the toolkit service from the 0.88 cycle with the shell service from 0.82 (since its API wasn't changed).
+Intermediate level libraries will be especially useful if their recent versions could be installed on every sugar in the field in spite of the sucrose release on particular machine. 0install is obvious choice since it is (see [[Activity Team/Services|Sugar Services]] to know more about 0install support in sugar):
+* Over GNU/Linux distribution mechanism
+* Could be install to user's home directory i.e. without having root privileges
+Other, but not less, useful 0install feature is having several versions of the code in the same time. For example if activity can work only with particular version of some intermediate library, it will work with this exact version even if it is really old, of course this library version should be still supported.
+== Activity developers point of view ==
+Having all mentioned above, activity developer needs only one thing to be sure that his activity will work on all sugars in the field - mention what intermediate libraries are needed and, maybe, what particular versions are. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services|Activity Developers Guide]] to know how it is implemented in 0sugar.
+So, to support huge repository of doer's code (see 3rd point of [[#Purposes|purposes]]), there is no need in having huge QA to review every new piece of code, we just rely on activity coder that he mentioned all required libraries/versions (he can just type all versions he had during activity coding).