[sugar] Relationships w/ upstream.

[Martin Langhoff]

On Mon, Jul 7, 2008 at 5:37 PM, C. Scott Ananian <cscott at laptop.org> 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
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff