Activity Team/Obsolete/Zero Sugar Use Cases

How Zero Sugar could be useful on examples.

Natively packaged or directly 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 distribution 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
• on end users side, sugar will understand that there are packaged and direct activity instances
• user(or distributor), by setting policy, can prefer only packaged versions
• user all time can pick up recent version from developer

Per user Sugar on a stick

Assuming that most of activities use Zero Sugar and activity developers want to support packagers (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 not python based activity, build code (for how many platforms/environments?)
• for activities that contain non Sugar Platform dependencies, need to mention it somewhere
• within sugar, only one stability activity versions exist

With Zero Sugar, developers:

• call 0sugar commit command to make newly created activity version accessible for users
• developer could release not only stable releases e.g. development, testing, users will know release stability status (without reading it somewhere) and by setting policy, could prefer only stable versions (or help to test development versions)

Easy activity deployment workflow

For now, users:

• find out .xo bundle somewhere e.g. on ASLO or wiki
• after downloading, have to be sured that activity will run in their environment e.g. for binary based activities, blobs were built for their platform or all non Sugar Platform dependencies are installed
• if activity was installed not from ASLO or distributor channel, have to manage activity versions on their own
• if they want to help with testing, have to fetch activity from source repositories or from not regular places like people.sugarlabs.org

With Zero Sugar, users:

• know, that every activity is identified by 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
• activity url could be picked up from everywhere, it could be emailed, passed via jabber message, posted on wiki
• user can help with testing activity just by setting policy (globally or for particular activity) and following regular procedures to launch it