Difference between revisions of "Deployment Platform/Declaration of purpose"

From Sugar Labs
Jump to navigation Jump to search
Line 31: Line 31:
 
:** Supporting environments with limited, or absent, access to the Internet;
 
:** Supporting environments with limited, or absent, access to the Internet;
 
:** Adapt ''Content'' to local needs.
 
:** Adapt ''Content'' to local needs.
 +
 +
''Who cares?''
 +
 +
:* Individual users;
 +
:* Content creators and software developers;
 +
:* Existing and potential Sugar deployments.
 +
 +
''If you're successful, what difference will it make?''
 +
 +
:* For individual users:
 +
:** reliable way to start Sugar on all mainstream platforms;
 +
:** environment to share content and activities which is well integrated to Sugar workflow.
 +
:* For content creators and software developers:
 +
:** easy sharing, e.g., system will handle issues like dependencies and building from sources automatically.
 +
:* For existing and potential Sugar deployments:
 +
:** sharing space that will be common to all participants (but it should support tuning content for local needs);
 +
:** more effectively reusing deployment experience, it will be incarnate in solutions on community level to reuse in any deployment.

Revision as of 07:03, 21 March 2012

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.

Who cares?

  • Individual users;
  • Content creators and software developers;
  • Existing and potential Sugar deployments.

If you're successful, what difference will it make?

  • For individual users:
    • reliable way to start Sugar on all mainstream platforms;
    • environment to share content and activities which is well integrated to Sugar workflow.
  • For content creators and software developers:
    • easy sharing, e.g., system will handle issues like dependencies and building from sources automatically.
  • For existing and potential Sugar deployments:
    • sharing space that will be common to all participants (but it should support tuning content for local needs);
    • more effectively reusing deployment experience, it will be incarnate in solutions on community level to reuse in any deployment.