Difference between revisions of "Deployment Platform/Declaration of purpose"
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.
- There is no system approach to provide the same Base software:
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.
- Open Build System for system approach to provide the same Base software:
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.
- For individual users: