On Mon, Jul 7, 2008 at 5:37 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > Since a conversation on IRC got unexpectedly heated, let me restate my > personal philosophy for OLPC's relationships with upstream:
I am surprised this got heated, you are right, and this isn't even controversial. This tension - "fork" / innovate ahead of upstream is a prevalent practice in FOSS. OLPC is a participant with a relatively well defined "client" and "use scenarios/cases" and we innovate and customise (at our cost) in ways that upstreams cannot or do not want to risk. If it pans out, the upstream can take it, if the feature / patch / ugly hack doesn't pan out, don't take it. Failure for free (for the upstream). Our incentives are clear - we want to bet carefully, and to win (in terms of forks that work out well enough that some version of it gets merged in upstream). > To the extent that sugarlabs is going to operate as a "true upstream", > they need to be cognizant of the fact that OLPC will at times put its ... > At the moment, I've been assured that upstream does *not* want to fork > sugar, and in fact will go out of its way, making special exceptions > for OLPC patches which conflict with sugar freezes. So this email is I though we were still our own upstream wrt sugar, but great to hear things are looking better for Sugarlabs. Probably means the sugar team gets larger :-) > That said, forks cost a lot. Definitely. I am all for picking carefully which ones to go for :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar