Difference between revisions of "Activity Team/Obsolete/Zero Sugar Use Cases"
< Activity Team | Obsolete
Jump to navigation
Jump to search
(Created page with '<noinclude> {{TOCright}} Category:Zero Sugar </noinclude> How Zero Sugar could be useful on examples. == What activity instance to prefer, ...') |
|||
| Line 6: | Line 6: | ||
How [[Activity Team/Zero Sugar|Zero Sugar]] could be useful on examples. | How [[Activity Team/Zero Sugar|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: | Zero Sugar could help with optimizing developer-to-distributor-to-user model. For example: | ||
| Line 12: | Line 12: | ||
* developer lets 0sugar create packages for major GNU/Linux distribution on OBS | * 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 | * 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, | + | * 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 | ||
Revision as of 01:28, 30 June 2010
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