Deployment Platform/Declaration of purpose

From Sugar Labs
< Deployment Platform
Revision as of 03:33, 21 March 2012 by Alsroot (talk | contribs) (Created page with "''What are you trying to do?'' :* The possibility to launch ''Base Software'' in heterogeneous software and hardware environments. :* Using ''Base Software'', provide access to ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

What are you trying to do?

  • The possibility to launch Base Software in heterogeneous software and hardware environments.
  • Using Base Software, provide access to various Content (Sugar activities, artifacts created by Sugar activities, books, etc.) created within the Sugar community.
  • Using Base Software, provide collaborative functionality to support Social activity around the Content.
  • Instruments and workflows to adapt Content and Base Software to specific needs that Sugar Deployment might face, including extreme ones like off-line environments and restricting hardware.

How is it done today, and what are the limits of current practice?

  • There is no system approach to provide the same Base software:
    • On different GNU/Linux distributions. That makes hard coordination, on Sugar Labs level, of any efforts related to Base software.
    • On Sugar Labs level, there are no LTS Sucrose releases. It makes hard coordination between Sugar deployments.
  • Current ways to share Content is either too general or limited:
    • The Activity Library is needless centralized (by design of upstream project that Activity Library is based on) and, e.g., doesn't accept uploading experimental activities created by not original authors.
    • Activity Library is too restricted (by upstream design, it was created to handle Firefox plugins) in case of not trivial software, e.g., dependencies and binary based activities.
    • No services, like Activity Library, to share something different to activities.
  • There is not centralized Sugar-way to support Social activity within the community:
    • There is a gap between developers and users in the field.
    • Existing social services either scattered or too technical.
  • There is not system approach, on Sugar Labs level, to coordinate efforts within the Sugar deployments.

What's new in your approach and why do you think it will be successful?

  • Open Build System for system approach to provide the same Base software:
    • The same code base is being built for all supported GNU/Linux distributions.
    • Among 6 months Sucrose releases, there will be supported LTS releases.
  • Sugar Network for system approach to provide Content.
    • That will include Sugar activities, the Sweets will take care about treating dependencies and Open Build System will build binaries in automatic manner.
  • Sugar Network for system approach to provide Social activity for the Content.
  • Sugar Network is designed to fulfill deployment needs like:
    • Supporting environments with limited, or absent, access to the Internet;
    • Adapt Content to local needs.