5,705
edits
Changes
Platform Team/Sugar Packaging Management System (view source)
Revision as of 08:04, 10 January 2010
, 08:04, 10 January 2010Created page with '== Purposes == Sugar is not unique when faces to questions like how to deploy new features to users. There is well tested and robust model in FOSS world when projects follow rel…'
== Purposes ==
Sugar is not unique when faces to questions like how to deploy new features to users. There is well tested and robust model in FOSS world when projects follow release(on regular bases) schedules e.g. 6month, support long time supported releases etc. But there could be cases when sugar has its specific:
* the most broad sugar audience is teachers, students, schools and other educational organizations thus not in all cases we can rely on the fact the all sugar users will use only last stable sugar release. For example last OLPC sugar is 0.82, next will be 0.84 but last stable is 0.86
* many developers participate on casual bases thus supporting several sugars(one for stable OLPC, one for next stable OLPC and one for last upstream stable) for theirs activities is overkill. Thus people support only one branch and either drop other users categories or do not implement useful features from last sugar(like 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 - centralized model with core team and regular releases and adding optional decentralization.
== Implementation ideas ==
Decentralized development model means here that activity developers' focus is moving from core releases to releases of services they use in activities.
So, the corner stone idea is not having solid sucrose, there could several sucrose releases in the field, but bunch of services(i.g. packages) that have their own [[Documentation_Team/Services/Service_Developers_Guide#Versioning_scheme|API based]] schedules. And so for over sugar dependencies like sugargame or groupthinking.
For glucose components it could look like:
* localize code that could be changed often to separate services with often releases
* keep the rest of code in services with infrequent releases
* use robust and explicit API for all services
For example in case of sugar-toolkit, it could be splited to:
* toolkit-shell, to incapsulate various shell related things
* toolkit-graphics, list of widgets that use stable API from toolkit-shell and mostly are shell independent
* toolkit-datastore, to wrap sugar-datastore API and will be released only with sugar-datastore
Sugar is not unique when faces to questions like how to deploy new features to users. There is well tested and robust model in FOSS world when projects follow release(on regular bases) schedules e.g. 6month, support long time supported releases etc. But there could be cases when sugar has its specific:
* the most broad sugar audience is teachers, students, schools and other educational organizations thus not in all cases we can rely on the fact the all sugar users will use only last stable sugar release. For example last OLPC sugar is 0.82, next will be 0.84 but last stable is 0.86
* many developers participate on casual bases thus supporting several sugars(one for stable OLPC, one for next stable OLPC and one for last upstream stable) for theirs activities is overkill. Thus people support only one branch and either drop other users categories or do not implement useful features from last sugar(like 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 - centralized model with core team and regular releases and adding optional decentralization.
== Implementation ideas ==
Decentralized development model means here that activity developers' focus is moving from core releases to releases of services they use in activities.
So, the corner stone idea is not having solid sucrose, there could several sucrose releases in the field, but bunch of services(i.g. packages) that have their own [[Documentation_Team/Services/Service_Developers_Guide#Versioning_scheme|API based]] schedules. And so for over sugar dependencies like sugargame or groupthinking.
For glucose components it could look like:
* localize code that could be changed often to separate services with often releases
* keep the rest of code in services with infrequent releases
* use robust and explicit API for all services
For example in case of sugar-toolkit, it could be splited to:
* toolkit-shell, to incapsulate various shell related things
* toolkit-graphics, list of widgets that use stable API from toolkit-shell and mostly are shell independent
* toolkit-datastore, to wrap sugar-datastore API and will be released only with sugar-datastore