michael wrote: > On Mon, Jul 28, 2008 at 11:26:28PM -0400, [EMAIL PROTECTED] wrote: > >the obvious answers are that we need to commit to some level of > >continuing support for activities, > > What notion of "support" would you suggest?
not breaking supplied interfaces without providing feedback to the activities that they're broken. commiting to a level of minimal interfaces. that sort of thing. > > > that we support the activities ourselves, > > As above. we clearly can't support all activities. i'm sure you realized it was a rhetorical suggestion. > > > or that we need to provide an extensible system so that > >activities can specify their dependencies (which will either lead > >to their fulfillment, or to the explicit disabling of the activity if > >they can't be fullfilled). > > Constraint satisfaction (i.e. dependency checking) is certainly one > approach; however, it is not universal; i.e. similar results can be > achieved with usage-outcome reporting technology driven by both manual > and automated regression testing. this isn't a good argument against dependency checking. and i'm not sure why we'd go out of our way to invent yet another new technology to support our system. > > See > > http://gsoc-sugarbot.blogspot.com/ > > for some active work in this direction. this looks like a testing framework. how does this help activity developers? (sorry -- i'm rushing, and don't have time to give it a full read.) > > >so far OLPC hasn't specified a minimal level of supplied > >services, or offered a way for activities to explicitly request > >services they know to be required. > > On the other hand, it would be rather trivial for activities which cared > to check their dependencies in a adhoc fashion (by running rpm > themselves if they wish) and by reporting errors if necessary > dependencies are unsatisfied. as someone else replied, this is far from trivial. > > > do you really think we can expect activity developers to maintain > > their code in "reaction mode", having to adapt to any change we make > > from release to release, only finding out about the breakage after the > > fact? > > I actually think that we [SugarLabs] should adopt an approach similar to > that taken by the Linux kernel (loosely paraphrased as): > > "we're going to make breaking changes but if you push your drivers > [activities] upstream, we'll help carry them along..." i'd point out that the continually breaking kernel interface is a serious problem for lots and lots of clients of the linux kernel, no matter how much the lkml believes otherwise. > > According to this suggestion, OLPC would contribute to the maintenance > of activities which are important to it as would any other employer of > SugarLabs coders. Overall responsibility for maintaining SL-designated > activities would rest with the SugarLabs community itself. i don't believe this model would work. open source works because by and large the traditional unix application environnment has been _incredibly_ stable -- the system call interface hasn't changed via deletion of a call in a very long time. when new interfaces or api's are introduced, a lot of effort is put into creating new stability: system calls are deprecated for years before being deleted, likewise for gtk api calls. system modules aren't simply removed -- they become separate packages that can be separately requested. open source developers (and i count myself among them) aren't the least bit interested in chasing a moving target -- they want a stable base on which to work. > > >can't think of a faster way to make developers give up on our > >platform as a lost cause. > > You need to be more imaginative. :) i'm not sure about that. :-) paul =--------------------- paul fox, [EMAIL PROTECTED] _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
