5,705
edits
Changes
Activity Team/Obsolete/Zero Sugar Use Cases (view source)
Revision as of 14:49, 25 November 2010
, 14:49, 25 November 2010no edit summary
{{Obsolete | It was only draft content}}
<noinclude>
<noinclude>
{{TOCright}}
{{TOCright}}
</noinclude>
</noinclude>
== Natively packaged or directly from developer activities? ==
== Natively packaged or direct from developer activities? ==
Zero Sugar could help with optimizing developer-to-distributor-to-user model. For example:
Zero Sugar could help with optimizing developer-to-distributor-to-user model. For example:
* developer lets 0sugar create packages for major GNU/Linux distribution on OBS
* Developer lets 0sugar create packages for major GNU/Linux distributions on OBS.
* distributors, either using native OBS features (like links and branches) create their own compilations of activities on OBS or just attach/copy OBS packages, compose repositories with activities for end users
* Distributors, either using native OBS features (like links and branches), create their own compilations of activities on OBS, or just attach/copy OBS packages, and so compose repositories with activities for end users.
* on end users side, sugar will understand that there are packaged and direct activity instances
* For end users, Sugar will understand that there are packaged and direct activity instances
* user(or distributor), by setting policy, can prefer only packaged versions
* The user (or distributor), by setting a policy, may prefer only packaged versions.
* user all time can pick up recent version from developer
* A user can always pick up a recent version from a developer.
{{Anchor|Per_user_Sugar_on_a_stick}}
== For Sugar on a Stick deployments ==
Assuming that most activities use Zero Sugar and activity developers want to support packagers (that is, use Zero Sugar OBS integration), it is possible to create live DVD/USB images on [http://wiki.opensuse.org/openSUSE:Build_Service_KIWI demand].
== Easy activity development workflow ==
For now, developers:
* create .xo bundles,
* choose server/service to host activity, e.g., ASLO or just upload .xo somewhere on wiki,
* for a non-Python-based activity, build code (for how many platforms/environments?).
* For activities that contain dependencies beyond those in the Sugar Platform, the developer needs to mention it somewhere.
* Within Sugar, only one 'stable' activity version exists.
With Zero Sugar, developers:
* call {{Code|0sugar commit}} command to make a newly created activity version accessible for users.
* The developer could release, not only stable releases, e.g., development, or testing releases, (users will know the release stability status, without reading it somewhere). And by setting a policy, one could prefer only stable versions (or help to test development versions).
== Easy activity deployment workflow ==
For now, users:
* find .xo bundle somewhere, e.g., on ASLO or wiki;
* after downloading, have to be sure that that the activity will run in their environment, e.g., for binary-based activities, blobs were built for their platform, or all extra-Sugar-Platform dependencies are installed.
* If activity was not installed from ASLO or a distributor channel, the users have to manage activity versions on their own.
* If they want to help with testing, they have to fetch the activity from source repositories or from irregular places, like people.sugarlabs.org.
With Zero Sugar, users:
* know, that every activity is identified by a URL, like http://go.sugarlsbs.org/My_Activity;
* can launch it from any (supported) environment, just by {{Code|sugar-launch http://go.sugarlsbs.org/My_Activity}} command or from UI.
* The activity URL could be picked up from anywhere, it could be emailed, passed via jabber message, posted on a wiki, etc.
* The user can help with testing an activity just by setting a policy (globally or for a particular activity) and following regular procedures to launch it.