Platform Team/Sugar Packaging Management System - Revision history

FGrose at 14:13, 3 July 2011

2011-07-03T14:13:08Z

← Older revision		Revision as of 10:13, 3 July 2011
Line 3:		Line 3:
	== Purposes ==		== 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:		Sugar is not unique when faced with questions such as how to deploy new features to users. There are well-tested and robust models in the FOSS world for projects that follow regular release schedules, e.g., 6-month, support, long-term supported releases, etc. But, there may be cases where Sugar has its own 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.		* The most broad Sugar audience includes teachers, students, schools and other educational organizations. Thus, we can not rely on the supposition that all Sugar users will use only the latest stable Sugar release. For example, the latest OLPC Sugar is <s>0.82, next will be 0.84, but the latest stable version is 0.88</s>.

	* 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).		* 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 too much work for them. 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 existing code and share their code. Having (in the ideal case) such a huge heap of code, we can't rely on the chance that all these activities will work on ~~a bunch of~~ Sugar releases. For example, if someone ~~took~~ the Record activity (maybe not the last version) and ~~implemented~~ a new feature, ~~and then~~ he just wants to share his hack, but not test this new code on several Sugar Platforms, or ask QA to test it, or ask ASLO editors to review etc., just share in a casual but still useful manner.		* One of Sugar's original purposes is stimulating people to hack existing code and share their code. Having (in the ideal case) such a huge heap of code, we can't rely on the chance that all these activities will work on so many Sugar releases. For example, someone may take the Record activity (maybe not the last version) and implement a new feature. Then, he just wants to share his hack, but not test this new code on several Sugar Platforms, or ask QA to test it, or ask ASLO editors to review, etc., just share it in a casual but still useful manner.

	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 that features regular releases—and add an optional, decentralized model.		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 that features regular releases—and add an optional, decentralized model.
Line 15:		Line 15:
	== Implementation ideas ==		== Implementation ideas ==

	Activity development could be based on ~~two~~ software-level solutions that are tied to each other.		Activity development could be based on a pair of software-level solutions that are tied to each other.

	=== Intermediate level libraries ===		=== Intermediate level libraries ===
Line 30:		Line 30:
	=== 0install deployment mechanism ===		=== 0install deployment mechanism ===

	Intermediate level libraries will be especially useful if their recent versions could be installed on every Sugar in the field whatever the Sucrose release on a particular machine. 0install is an obvious choice since it is:		Intermediate level libraries will be especially useful if their recent versions could be installed on every Sugar in the field, whatever the Sucrose release on a particular machine. 0install is an obvious choice since it is

	* An overall GNU/Linux distribution mechanism,		* An overall GNU/Linux distribution mechanism,
Line 41:		Line 41:
	== Activity developer's point of view ==		== Activity developer's point of view ==

	Having covered all the above, an activity developer needs only one thing to be sure that his activity will work on all Sugars in the field: Declare what intermediate libraries are needed and, maybe, what particular versions are needed. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services\|Activity Developers Guide]] to learn how it is implemented in 0sugar.		Having covered all the above, an activity developer needs only assure one thing to be sure that his activity will work on all Sugars in the field: Declare what intermediate libraries are needed and, maybe, what particular versions are needed. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services\|Activity Developers Guide]] to learn how it is implemented in 0sugar.

	So, to support a huge repository of Learner's/doer's code (see 3rd point of [[#Purposes\|purposes]]), there is no need in having a huge QA effort to review every new piece of code, we just rely on the activity coder having declared all required libraries/versions (~~he can just type all versions he had~~ during activity coding).		So, to support a huge repository of Learner's/doer's code (see 3rd point of [[#Purposes\|purposes]]), there is no need in having a huge QA effort to review every new piece of code—we just rely on the activity coder having declared all the required libraries/versions (those used during activity coding).

Alsroot: moved Platform Team/Scalable development model to Platform Team/Sugar Packaging Management System

2011-07-03T10:19:29Z

moved Platform Team/Scalable development model to Platform Team/Sugar Packaging Management System

← Older revision	Revision as of 06:19, 3 July 2011
(No difference)

Alsroot at 21:33, 25 November 2010

2010-11-25T21:33:21Z

← Older revision		Revision as of 17:33, 25 November 2010
Line 26:		Line 26:
	* Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.		* Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.

	See [[~~Activity_Team~~/Polyol\|Polyol group]] to learn about a possible implementation.		See [[Platform_Team/Polyol\|Polyol group]] to learn about a possible implementation.

	=== 0install deployment mechanism ===		=== 0install deployment mechanism ===

Alsroot at 21:29, 25 November 2010

2010-11-25T21:29:48Z

← Older revision		Revision as of 17:29, 25 November 2010
Line 1:		Line 1:
	~~<noinclude>~~
	~~{{TOCright}}~~
	~~[[Category:Activity Team]]~~
	~~[[Category:Services/Documentation]]~~
	~~</noinclude>~~

	Important note, this text is about community-driven processes that are decentralized by design. Deployment organisations like OLPC are more centralized by their nature and have absolutely different deployment schemes. And, of course, both schemes are important and useful.		Important note, this text is about community-driven processes that are decentralized by design. Deployment organisations like OLPC are more centralized by their nature and have absolutely different deployment schemes. And, of course, both schemes are important and useful.

Alsroot: moved Activity Team/Zero Sugar/Scalable development model to Platform Team/Scalable development model

2010-11-25T21:29:01Z

moved Activity Team/Zero Sugar/Scalable development model to Platform Team/Scalable development model

← Older revision		Revision as of 17:29, 25 November 2010
(No difference)

Alsroot: moved Documentation Team/Services/Scalable development model to Activity Team/Zero Sugar/Scalable development model

2010-06-26T11:22:16Z

moved Documentation Team/Services/Scalable development model to Activity Team/Zero Sugar/Scalable development model

← Older revision		Revision as of 07:22, 26 June 2010
(No difference)

Patrol at 19:32, 26 April 2010

2010-04-26T19:32:24Z

Alsroot: /* Implementation ideas */

2010-04-26T18:46:36Z

Implementation ideas

← Older revision		Revision as of 14:46, 26 April 2010
Line 31:		Line 31:
	* 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.		* 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.		* Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.

			See [[Activity_Team/Polyol\|Polyol group]] to know about possible implementation.

	=== 0install deployment mechanism ===		=== 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 [[Activity Team/Services\|Sugar Services]] to know more about 0install support in sugar)~~:		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:

	* Over GNU/Linux distribution mechanism		* Over GNU/Linux distribution mechanism
Line 40:		Line 42:

	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.		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.

			See [[Activity Team/Services\|Sugar Services]] to know about possible implementation.

	== Activity developers point of view ==		== Activity developers point of view ==

Alsroot: /* Purposes */

2010-04-26T18:43:25Z

Purposes

← Older revision		Revision as of 14:43, 26 April 2010
Line 4:		Line 4:
	[[Category:Services/Documentation]]		[[Category:Services/Documentation]]
	</noinclude>		</noinclude>

			Important note, this text is about community driven process that are decentralized by design. Deployment organisations like OLPC are more centralized by their nature and have absolutely different deployment schemes. And of course both schemes are important and useful.

	== Purposes ==		== Purposes ==

Alsroot: /* Implementation ideas */

2010-04-26T18:38:17Z

Implementation ideas

← Older revision		Revision as of 14:38, 26 April 2010
Line 19:		Line 19:
	== 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~~.		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).

← Older revision		Revision as of 15:32, 26 April 2010
Line 5:		Line 5:
	</noinclude>		</noinclude>

	Important note, this text is about community driven ~~process~~ that are decentralized by design. Deployment organisations like OLPC are more centralized by their nature and have absolutely different deployment schemes. And of course both schemes are important and useful.		Important note, this text is about community-driven processes that are decentralized by design. Deployment organisations like OLPC are more centralized by their nature and have absolutely different deployment schemes. And, of course, both schemes are important and useful.

	== Purposes ==		== 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:		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.		* 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).		* 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.		* One of original Sugar purposes is stimulating people to hack existing code and share their code. Having (in the ideal case) such a huge heap of code, we can't rely on the chance that all these activities will work on a bunch of Sugar releases. For example, if someone took the Record activity (maybe not the last version) and implemented a new feature, and then he just wants to share his hack, but not test this new code on several Sugar Platforms, or ask QA to test it, or ask ASLO editors to review etc., just share in a casual but still useful manner.

	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.		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 that features regular releases—and add an optional, decentralized model.

	== Implementation ideas ==		== Implementation ideas ==

	~~There~~ could be two level solutions that are tied to each other.		Activity development could be based on two software-level solutions that are tied to each other.

	=== Intermediate level libraries ===		=== 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''.		A decentralized development model here means that the activity developers' focus is moved from core releases to releases of core libraries that they use in activities. So, the cornerstone idea is switching from a ''monolithic Sucrose'' + ''activities'' scheme to a ''monolithic Sucrose'' + ''intermediate level libraries'' + ''activities''.

	The major purposes in having intermediate level libraries are:		The major purposes in having intermediate software-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.		* Support several Sucrose releases that are popular in deployments right now, so activity developers won't have to code a bunch of if statements to support several Sucrose releases, they just use what current, intermediate libraries can provide and the 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.		* Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.

	See [[Activity_Team/Polyol\|Polyol group]] to ~~know~~ about possible implementation.		See [[Activity_Team/Polyol\|Polyol group]] to learn about a possible implementation.

	=== 0install deployment mechanism ===		=== 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:		Intermediate level libraries will be especially useful if their recent versions could be installed on every Sugar in the field whatever the Sucrose release on a particular machine. 0install is an obvious choice since it is:

	* ~~Over~~ GNU/Linux distribution mechanism		* An overall GNU/Linux distribution mechanism,
	* Could be ~~install~~ to user's home directory i.e. without having root privileges		* Could be installed to the 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.		Another, but no-less-useful 0install feature is having several versions of the code at the same time. For example, if an activity can work only with a particular version of some intermediate library, it should work with this exact version even if it is really old, of course, this library version should be still supported.

	See [[Activity Team/Services\|Sugar Services]] to ~~know~~ about possible ~~implementation~~.		See [[Activity Team/Services\|Sugar Services]] to learn about possible implementations.

	== Activity ~~developers~~ point of view ==		== Activity developer's 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.		Having covered all the above, an activity developer needs only one thing to be sure that his activity will work on all Sugars in the field: Declare what intermediate libraries are needed and, maybe, what particular versions are needed. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services\|Activity Developers Guide]] to learn 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).		So, to support a huge repository of Learner's/doer's code (see 3rd point of [[#Purposes\|purposes]]), there is no need in having a huge QA effort to review every new piece of code, we just rely on the activity coder having declared all required libraries/versions (he can just type all versions he had during activity coding).