Sugar Labs

Activity Team/Obsolete/Zero Sugar Use Cases

< Activity Team‎ | Obsolete
Revision as of 16:52, 6 July 2010 by FGrose (talk | contribs)



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.
Retrieved from "https://wiki.sugarlabs.org/index.php?title=Activity_Team/Obsolete/Zero_Sugar_Use_Cases&oldid=54096"