Relationships w/ upstream.

[C. Scott Ananian]

Since a conversation on IRC got unexpectedly heated, let me restate my
personal philosophy for OLPC's relationships with upstream:

(a) I believe that we should put OLPC's goals *first*, and endeavor to
ensure that we are always meeting the actual needs of our clients,
forking whenever upstream's goals/process/schedule interfere with
OLPC's ability to actually ship software responsive to its needs and
its client's needs.

(b) That said, I acknowledge that forks have a huge long-term cost,
and that in order to effectively develop software with a small group
of developers we can't afford to keep paying fork costs over and over
again.  Thus, we also have a responsibility to work closely with
upstream to prevent the necessity of a fork.

These goals are in conflict, and my "position in arguments" has
changed over time, depending on whether the "other side" is being
adequately represented.  These days, I rely on Dennis Gilmore to hold
firm to the "forks must be prevented at all costs" side of the
argument, which frees me to make the "OLPC's goals first" argument --
the compromises between Dennis and I then chart the middle ground
between the two conflicting goals: ensuring that we don't let process
bureaucracy prevent us from actually solving problems, while at the
same time ensuring that our zeal to "fix it, and fast" doesn't prevent
us from making the investments in upstream needed to reduce our
long-term costs.

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
goals/process ahead of "upstream's" goals/process.  In theory, this
means that OLPC would probably fork sugarlab's upstream packages so
that it can, for example, make "important" changes to sugar that
conflict with "upstream's" goals.  This is complicated by the fact
that the same people would currently maintain both the "upstream"
sugar packages and the "OLPC forked" packages, and they may find it
difficult to wear two different hats at the same time: evaluating a
potential patch in terms of "is it best for sugarlabs" on one hand,
and in terms of "is it best for OLPC" on the other.

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
not particularly responding to a *present* problem: it is instead
pointing out the possibility of future conflict, and noting that
sugarlabs folks should not be surprised to find that OLPC's
goals/needs conflict with their own, and that OLPC may in the future
even fork sugar.  This is not because we are attributing "malign
intent" to the sugar developers (as was claimed at one point) -- in
fact, the very opposite: the purpose of creating an OLPC-specific fork
would be to allow sugar to better pursue its independent schedules.
In this way, ultimately, sugar would be treated just like all the rest
of our upstreams.

That said, forks cost a lot.  I hope we will not have to fork sugar,
even in minor ways, anytime soon.
 --scott

(Context: current high-priority sugar bugs for 8.2:
http://dev.laptop.org/ticket/7380, http://dev.laptop.org/ticket/7381;
fixing these might conflict with sugar's self-imposed string freeze,
even though 8.2 has not yet frozen its strings.)

-- 
 ( http://cscott.net/ )