On Sat, 2010-03-13 at 20:50 +0000, Gary C Martin wrote: > Agreed, though this argument only really works if the changes > each time are easy to install from the user perspective with > no loss of data. I wish we were doing much better here.
Me too, but it's not as bad as it seems: the techies use a simple shell script to backup and restore the journal (and scratch data) across updates. The script doesn't backup any Sugar settings, so users get to the initial setup screen when they're handed back their laptops. Nobody ever complains about this, but it would be easy to do. To save time, only teachers' journals are being preserved across updates. Kids don't seem to care at all, they voluntarily come and beg the technicians to upgrade their laptops so they could use "Piecito". > It feels uncomfortable that Sugar 0.84 is already a year old effort > as of this week, from its official release, too far ahead of > deployments? It seems we should try to shorten our "time to market". Both Fedora and SoaS have been trailing Sugar releases quite well. Instead, OLPC appears to have frozen on Fedora 11 much too early. Both Sugar and Fedora are aligned on a predictable, 6-months release cycle, so it's safe for downstream projects to pick a version which is expected a few months before the target release date. Stability is a classic justification for longer release cycles, starting with a selection of well seasoned packages. The problem with this approach is that, by the time it reaches the first user, all software is already abandonware. Upstream developers are working 3 versions ahead of you and tend to ignore all your bug reports. So you end up backporting all the fixes you need on your own, which tends to be hard and risky because meanwhile the codebase has changed so much. One would think that a relatively fixed platform like the XO-1 could lag behind on hardware support without consequences, but users have the bad habit of demanding that a 3G modem purchased last week would work on a version of Fedora released one year ago. So you end up back-porting large pieces of Fedora 12--breaking who knows what else--while the udev maintainer asks you to keep him informed on your progress. So much for the good intentions of stability. Not to mention dependencies: many of the bugs found in Sugar activities by your testers seem to have been fixed in new upstream releases... which require Sugar 0.86 minimum. Bummer! Given enough time and money, one could even stabilize Windows Vista. However, the most efficient use of our scarce resources would be to reduce version diversity across downstream distributors in order to share the burden of maintaining all them. The educational nature of Sugar puts one additional constraint on us: software updates are best done at the beginning of every school year, which varies wildly from one nation to the other. Given our 6-months cycles, at any time we'd have todeal with a minimum of 2 Sugar releases in parallel. Not ideal, but still better than the current situation in which we start a school year with a version of Sugar released over one year ago. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel