Difference between revisions of "Activity Team/Obsolete/Zero Sugar Use Cases"
< Activity Team | Obsolete
Jump to navigation
Jump to search
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Obsolete | It was only draft content}} | ||
| + | |||
<noinclude> | <noinclude> | ||
{{TOCright}} | {{TOCright}} | ||
| − | |||
</noinclude> | </noinclude> | ||
| − | |||
| − | == Natively packaged or | + | == 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 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, and so compose repositories with activities for end users. |
| − | * | + | * For end users, Sugar will understand that there are packaged and direct activity instances |
| − | * user(or distributor), by setting policy, | + | * The user (or distributor), by setting a policy, may prefer only packaged versions. |
| − | * user | + | * 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 | + | 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 == | == Easy activity development workflow == | ||
For now, developers: | For now, developers: | ||
| − | * create .xo bundles | + | * create .xo bundles, |
| − | * choose server/service to host activity e.g. ASLO or just upload .xo somewhere on wiki | + | * choose server/service to host activity, e.g., ASLO or just upload .xo somewhere on wiki, |
| − | * for | + | * 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: | With Zero Sugar, developers: | ||
| − | * call {{Code|0sugar commit}} command to make newly created activity version accessible for users | + | * call {{Code|0sugar commit}} command to make a newly created activity version accessible for users. |
| − | * developer could release not only stable releases e.g. development, testing, users will know release stability status | + | * 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 == | == Easy activity deployment workflow == | ||
For now, users: | For now, users: | ||
| − | * find | + | * find .xo bundle somewhere, e.g., on ASLO or wiki; |
| − | * after downloading, have to be | + | * 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: | With Zero Sugar, users: | ||
| − | * know, that every activity is identified by | + | * 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 | + | * can launch it from any (supported) environment, just by {{Code|sugar-launch http://go.sugarlsbs.org/My_Activity}} command or from UI. |
| − | * activity | + | * The activity URL could be picked up from anywhere, it could be emailed, passed via jabber message, posted on a wiki, etc. |
| − | * user can help with testing activity just by setting policy (globally or for particular activity) and following regular procedures to launch it | + | * 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. |
Latest revision as of 13:49, 25 November 2010
Natively packaged or direct from developer activities?Zero Sugar could help with optimizing developer-to-distributor-to-user model. For example:
For Sugar on a Stick deploymentsAssuming 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 demand. Easy activity development workflowFor now, developers:
With Zero Sugar, developers:
Easy activity deployment workflowFor now, users:
With Zero Sugar, users:
|
