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 == [EMAIL PROTECTED] should become [EMAIL PROTECTED] . OLPC specific issues should be discussed on [EMAIL PROTECTED] . == 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
