[sugar] SugarLabs and OLPC

[Marco Pesenti Gritti]

Hello,

there has been a bit of confusion on how the OLPC and SugarLabs
schedules relates, in particular regarding translation and string
freeze.

http://lists.laptop.org/pipermail/localization/2008-July/001139.html

I'm trying to think more in general about how to shape up the
upstream/downstream relation. My goals are:

* Gradually turn Sugar into a real upstream project. It should be easy
to distribute outside the OLPC context. And it should be easy for
non-OLPC developers to participate.
* Do not make the life of OLPC developers and testers harder. Make
responsibilities clear and transparent. Keep duplication at minimum.

Here are some concrete proposals.

== Schedule ==

Sugar has his own roadmap and schedule:

http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap

We need to ensure that this schedule is compatible with OLPC needs.
Given that OLPC committed to time based releases, I don't expect any
issue on this front.

We will need to know with some advance the target date of the OLPC
release though, to do it properly. It didn't happen for 8.2.0, because
the whole process is still being defined, but I expect it will happen
in the future.

== Localization ==

Localization of Glucose and Fructose should happen upstream, following
the Sugar schedule. Ideally pootle would be hosted by SugarLabs, but
even just creating separate groups on dev.laptop.org/translate would
be a good start.

There is the issue of how to handle activities which are not included
in Fructose. My gut feeling is that we should:

1 Encourage as many activities as possible to follow the Sugar
schedule (not necessarily by being included in Fructose).
2 Work upstream for the rest of the activities.

We could create the following groups in pootle:

* Glucose
* Activities (following the Sugar schedule)

I'm not sure it make sense to have a group for activities which
doesn't follow the schedule. Perhaps we should offer pootle for these
projects anyway to make their life easier, but without including them
in any official group.

We need to setup a Localization team on wiki.sugarlabs.org . I'm
actually surprised we don't have one already. I will start a separate
thread about that.

== Source code ==

Source code repositories for Glucose and all the activities should be
hosted at SugarLabs.

We are going to provide something like http://trac-hacks.org/ , where
each project has his own code repositories, trac instance, wiki etc.
I'm not sure yet if Fructose activities should have each one their own
project space, or if they should be part of a Fructose project, or if
Glucose+Fructose should all be under a Sugar project. Anyway that will
not impact OLPC much, it can be discussed separately.

== Mailing lists ==

sugar at laptop.org should become devel at sugarlabs.org . OLPC specific
issues should be discussed on devel at laptop.org .

== Trac ==

This is probably the most tricky one.

I propose that tickets reported by OLPC clients and OLPC QA team (or
issues which affect OLPC clients as gathered by Greg and the OLPC
learning team) keep being tracked at dev.laptop.org for the time
being. It's a little unusual compared to other distributions, where
people are generally asked to report bugs upstream, but OLPC is
currently the only real Sugar deployment and it would *very*
impractical to introduce overhead to escalate tickets upstream.

SugarLabs will have his own trac instance(s) to cover:

* TODO like issues opened by developers. Ex: "Refactor the messy code
in sugar.shell.something"
* Issues which affects non-OLPC clients. Ex: "Sugar is broken on a
800x600 screen"
* Issues which affects activities *not* supported by OLPC. (It's not
yet clear which
of them will be supported if any.)


How does it sound? Can you think of important pieces of infrastructure/process
which are *not* covered here?

Marco