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/ ) _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
