Difference between revisions of "Platform Team/Sugar Packaging Management System"
Jump to navigation
Jump to search
m (moved Walter is a wanker 9/Services/Scalable development model to Documentation Team/Services/Scalable development model over redirect: revert) |
(work on English) |
||
| Line 7: | Line 7: | ||
== Purposes == | == Purposes == | ||
| − | Sugar is not unique when | + | 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.86. |
| − | * | + | * 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). |
| − | So, the right answer could be more scalable and decentralized development model. That doesn't mean we should follow only decentralized model but we can effectively mix both | + | 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 == | == 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. | |
| − | So, the corner stone idea is not having | + | 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. |
| − | For glucose components it could look like: | + | For glucose components, it could look like the following: |
| − | * | + | * Localized code that could be changed often to separate services with frequent releases. |
| − | * | + | * Keep the rest of the code in services with infrequent releases. |
| − | * | + | * Use robust and explicit APIs for all services. |
| − | For example in case of sugar-toolkit, it could be | + | For example, in the case of sugar-toolkit, it could be split: |
| − | * | + | * 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. |
| − | * | + | * 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 independent | + | 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). |
Revision as of 19:27, 6 March 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.86.
- 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).
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
A decentralized development model means here that the activity developers' focus is moved from core releases to releases of services they use in activities.
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 API-based schedules and similar for other sugar dependencies, like sugargame or groupthink.
For glucose components, it could look like the following:
- Localized code that could be changed often to separate services with frequent releases.
- 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:
- 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.
- 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).