Activity Team/Obsolete/Zero Sugar Use Cases

How Zero Sugar could be useful with examples.

Natively packaged or direct from developer activities?

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
• The user (or distributor), by setting a policy, may prefer only packaged versions.
• A user can always pick up a recent version from a developer.

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