Activity Team/Obsolete/Zero Sugar Use Cases

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.