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? > that we support the activities ourselves, As above. > 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. See http://gsoc-sugarbot.blogspot.com/ for some active work in this direction. >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. > 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..." 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. >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. :) Michael _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
