On Mon, 2010-03-15 at 10:46 -0500, Martin Langhoff wrote: > On Sun, Mar 14, 2010 at 1:17 AM, Bernie Innocenti <ber...@codewiz.org> wrote: > > 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 > > So no XS in place?
The repair lab is not nearby any of the schools. > Downstreams that go to deployment (OLPC!) want to wait until a release > is reasonably well tested and stabilised. We have a chicken-and-egg problem: deployments have to participate in testing (and development), otherwise no bugs will ever be fixed. > > Stability is a classic justification for longer release cycles > > The thing is: stabilisation takes time. These users are not > programmers, nor geeks. They are not the Fedora hard-core "gimme the > latest even if broken". They are teachers and children in a school. > > I don't mess with my editor or my version control system often. emacs > updates have messed up my life, so I don't do them in the middle of a > project. Similarly, teachers won't want frequent updates, or updates > that are broken (in Sugar core, or in activity compatibility!). Letting volunteer children and teachers test the software has been incredibly productive. I wish I could have started one month earlier, so there would have been enough time to fix most problems before schools reopened in LatAm. A few trainers who were asked to test new builds much explanation complained for the annoyances without providing enough information for a bug report. Considering that most of them were exposed to computers for the first time in their lives just a couple of months ago, it's no wonder they were unable to distinguish between hardware and software problems. I filed a few real bugs last week, and this week I'll spend a few full days side by side with the trainers to see what issues are still bothering them. > That is only true if the dev team only cares about the hardcore geeks > that want the latest and greatest. > > If the dev team cares about end users, then it's not abandonware. Which dev team? There are many: Sugar Labs, OLPC, Fedora, and all the other upstream projects we depend upon. Now I have a problem with udev which is unlikely to be fixed by upstream. The maintainer *does* care about end users, but he'd rather spend his time supporting the current user base than the legacy Fedora 11 which is soon going end-of-life. Same goes for the activities developers: maintaining compatibility with 3-4 releases of Sugar is prohibitive. Backporting bugfixes is also very expensive in terms of time and not something that volunteers are likely to do spontaneously. OLPC allocated developers to maintain the Sugar 0.84 and related activities, but it would save time if we could stay closer the latest Fedora and the latest Sugar, at least at release time. > > 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. > > Agreed. One path is to release less often. Or to mark certain releases "LTS". I've been suffering with RHEL for a while and I'm sure Ubuntu LTS has the same problem: no support for new hardware, ancient versions of software which don't interact well with the rest of the world... I think it would work well if one could freeze the whole universe at the time of the LTS release. > Yep. You could make it a "major / minor" pair. So you only have one > LTS per year. > > "Developer" releases can happen more often. One year of slack between development and user release would be ideal. By LTS, I thought you meant 5 years :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel