Re: [sugar] Relationships w/ upstream.
On Mon, 2008-07-07 at 16:37 -0400, C. Scott Ananian wrote: > 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. I don't think we need to worry very much about this issue. Once we, OLPC and SL, get our release schedules and process worked out. These issues will work themselves out. Pretty soon, Sugar Labs will be pushing a new release out every six months. There was a thread a few weeks ago about OLPC releasing every six months and SL basing our release on the lead time OLPC needs do prepare a Sugar tarball for release. To keep things in perspective, remember the horrendous release problems Debian had a few years ago:) They seem to have gotten them pretty well resolved lately. dfarning ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 5:29 PM, Martin Langhoff <[EMAIL PROTECTED]> wrote: > On Mon, Jul 7, 2008 at 6:17 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: >> I think we're all agreed that even small forks have large long-term >> costs, and we'd prefer to avoid them where at all possible -- which we >> all agree seems to be the case at present. > > Here I disagree - small and medium sized forks can be low cost, and > highly dynamic, specially when you are using a merge-friendly SCM > (git!). I have at various times longed for a way to make small forks from upstream less painful, so that we can use them more aggressively. But, putting on my other hat (the "Dennis" hat), I'd say that there's a big difference between "no fork" and "some fork", even though (as you point out) there may be very little difference between a small and medium fork, once you've got one. There's a lot of mental and bookkeeping overhead to make sure that your small fork stays in place, gets updated properly, that end users can distinguish between the forked version and upstream when they do maintenance or development, etc, etc. > - I think we are overstressing about a bunch of strings. People We are probably overstressing. And I probably overreacted on IRC, triggering the conflict in the first place. We all seem to agree now, at least. =) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 6:17 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > I think we're all agreed that even small forks have large long-term > costs, and we'd prefer to avoid them where at all possible -- which we > all agree seems to be the case at present. Here I disagree - small and medium sized forks can be low cost, and highly dynamic, specially when you are using a merge-friendly SCM (git!). The last 6 years of my life have been working with projects that ran ahead of their upstreams -- mostly moodle -- and things were horribly painful before git. Once git was usable, it just became a matter of a bit of discipline. - Long term forks are death, short term forks are opportunity. - Sugar isn't a forking problem :-) as olpc team and sugar team overlap significantly. - I think we are overstressing about a bunch of strings. People rightly say that forks are costly and nightmarish, but they are talking about a few thousand patches, and deltas of 10K lines, that when merged resulted in a few hundred gnarly conflicts. Strings you say? I landed 130 patches worth 4K lines of diff between 1.8 and 1.9 of moodle, rewriting one of the core libs completely :-) 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Relationships w/ upstream.
On 7/7/08, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Mon, Jul 7, 2008 at 4:56 PM, Walter Bender <[EMAIL PROTECTED]> > wrote: >> I'll be presumptuous and speak on behalf of "upstream." Sugar >> developers are cognizant of the needs of OLPC and will go out of their >> way to make sure that the (by far) largest Sugar deployment is >> successful. Has this been questioned? > > No, and it's good to hear regardless. +1 on what walter said. >>> 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. >> >> At present, there is no reason to fork Sugar that I am aware of and as >> with any project, there is a mechanism for requesting "special >> exceptions", for example CJB's request regarding OHM and the Sugar >> Control Panel. >> >> It is hard to tell from #7381 what the heated discussion on IRC may >> have been about. There is certainly not consensus regarding the merits >> of the "free-form" Home View, but it is being accepted upstream, >> AFAIK. We do plan some user studies of this View, the results of which >> may (or may not) be compelling evidence to reopen this decision. > > Yes, things are going well right now, and the current issues are not > problematic. I was just trying to preemptively communicate > expectations, so that any future minor fork of sugar is not seen as > adversarial, but instead a natural solution to allow decoupled > development -- in the same way we use small forks to handle such > issues in other components (such as telepathy, initscripts, etc). That makes totally sense to me. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Relationships w/ upstream.
On Mon, Jul 7, 2008 at 4:56 PM, Walter Bender <[EMAIL PROTECTED]> wrote: > I'll be presumptuous and speak on behalf of "upstream." Sugar > developers are cognizant of the needs of OLPC and will go out of their > way to make sure that the (by far) largest Sugar deployment is > successful. Has this been questioned? No, and it's good to hear regardless. >> 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. > > At present, there is no reason to fork Sugar that I am aware of and as > with any project, there is a mechanism for requesting "special > exceptions", for example CJB's request regarding OHM and the Sugar > Control Panel. > > It is hard to tell from #7381 what the heated discussion on IRC may > have been about. There is certainly not consensus regarding the merits > of the "free-form" Home View, but it is being accepted upstream, > AFAIK. We do plan some user studies of this View, the results of which > may (or may not) be compelling evidence to reopen this decision. Yes, things are going well right now, and the current issues are not problematic. I was just trying to preemptively communicate expectations, so that any future minor fork of sugar is not seen as adversarial, but instead a natural solution to allow decoupled development -- in the same way we use small forks to handle such issues in other components (such as telepathy, initscripts, etc). I think we're all agreed that even small forks have large long-term costs, and we'd prefer to avoid them where at all possible -- which we all agree seems to be the case at present. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Relationships w/ upstream.
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Relationships w/ 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 > goals/process ahead of "upstream's" goals/process. I'll be presumptuous and speak on behalf of "upstream." Sugar developers are cognizant of the needs of OLPC and will go out of their way to make sure that the (by far) largest Sugar deployment is successful. Has this been questioned? > 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. At present, there is no reason to fork Sugar that I am aware of and as with any project, there is a mechanism for requesting "special exceptions", for example CJB's request regarding OHM and the Sugar Control Panel. It is hard to tell from #7381 what the heated discussion on IRC may have been about. There is certainly not consensus regarding the merits of the "free-form" Home View, but it is being accepted upstream, AFAIK. We do plan some user studies of this View, the results of which may (or may not) be compelling evidence to reopen this decision. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
