[Sugar-devel] Hi; GSoC?

[Aleksey Lim]

On Thu, Mar 18, 2010 at 11:43:22AM -0400, Benjamin M. Schwartz wrote:
> Isaac Dupree wrote:
> > I wonder if this Zero/Sugar 
> > project could use some GSOC support, or if there are more 
> > useful/important things to work on?
> 
> I think 0install+Sugar integration would be a very valuable project.  The
> Sugar Labs Oversight Board recently approved a statement that Sugar needs
> "a mechanism for supporting access to non-Sugar dependencies".  I think
> 0install fits the bill well.
> 
> There are many Sugar developers who are skeptical of 0install's utility
> for Sugar.  I think a GSoC project to add deep 0install support to the
> Sugar core would be a great way to resolve this issue.  If the GSoC
> project produces a compelling result, then perhaps more developers will be
> convinced, and the project's code can be committed to Sugar mainline.
> 
> There are many aspects to 0install, so you might want to focus your
> efforts on some subset of the 0install system.  Some examples:
> 
> Enable 0share for local sharing of Activities.
> Use 0install's cryptographic identifiers as indices in a commenting system
> ("This activity is super-fun and never crashed for me.")
> Add 0mirror support to the school server (XS), possibly integrated with
> ASLO mirroring.
> Use 0test to improve Activity reliability across different Sugar versions,
> distros and hardware.
> Add 0compile to Sugar for running on unusual architectures (e.g. MIPS)
> Add 0publish support to the Develop activity, so that users can easily
> create and publish Activities.
> Add 0install support to the Journal.

Just a sumary what was already done in 0sugar:

* 0sugar tool [1], something like high level packaging wraper aroud pure
  0install (e.g. creating rpm from spec files)
  - convenient tool to wrap projects exsited/packaged/new to 0install feeds
  - build binary based projects in maintener environment and in users
    environment as well
  - hosting 0sugar projects, by one commnd 0sugar project will be
    uploaded to the right place and be ready for using

* 0sugar-inject and 0sugar-launch tools [2], let activity developers use
  0sugar project as external dependencies and if there is such need,
  budnle all deps to xo, it already works well for a half of ASLO
  activities

Some points to do:

* Bulild farm for binary based 0sugar projects
  - since building 0sugar projects should be not common practice (in
    most cases there is not need in 0sugar itest, in other cases
    dependency could be python based or rely on distro packages) we can
    setup such build farm in our environment and integrate it w/ 0sugar tool
    (by one command project will be send to build farm)
  - reuse existed build farms e.g. opensuse's, could be not useful e.g.
    in cases when we need build recent pygame for XO-1 env (all exsted
    distros don't contain fc9 versions and recent pygame at the same
    time)

* Turn activity bundles into 0install feeds [3]
  e.g. it gives us a chance to preserve fully bundled .xo i.e. 0activities
  could obviousle distinguished from .xo

..and like was laready mentioned..

* closer integration of 0sugar and shell, not sure if start hacking
  current Journal is the right way [4]
  - full cycle of using 0sugar activities
  - 0sugar integration
  - ...

* ...


[1] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Activity_Developers_Guide
[2] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Service_Developers_Guide
[3] http://wiki.sugarlabs.org/go/Features/Zero_Sugar_Activities
[4] http://lists.sugarlabs.org/archive/sugar-devel/2010-March/023047.html

-- 
Aleksey