I'm not sure about the hardware issues mentioned below, as new to some of these lists, but if there is an installed base of XO-1 computers with special hardware like the touchpad with 2 extra areas that were never implemented, why not develop applications for those, even if the XO-1.5 and XO-2 plans don't include them?
What are you going to tell the kids with XO-1s when the XO-1.5 come out? What is the consolation prize? Knowing more about it, and being further up the learning curve? Also, the battery issues will get worse, as the hardware gets older, so testing and determining when need new battery, as a computer without power isn't much fun. Repairing hardware gets more crucial as machines get older. Being more inventive with what you have instead of this is the shiny new machine, so going deeper into the system, maybe programming instead of just using. Or more time with the learning content. Even as a ebook reader, getting new content, creating new content, maybe more translating content? I still think flossmanuals.net needs indexing and other layout stuff, under the hood, or however parallel, LyX makes some assumptions, and does some of that but not the wiki and social stuff up top, so [La]TeX classes and styles might be a good contribution, finding objavi and booki source code, etc... The requirements for testing a new build is some extra XO-n hardware for testing, and a high speed connection, if giving new .isos builds out to the world, or access to some place that would, plus the time and knowledge to make the changes, find bugs, report them, etc. And if 'It's An Eduction Project" are we teaching self reliance and how to do builds, make your own constructionist style or whatever teaching paradigm fits the locals? Or forcing dependence upon others? My $.02 USD - costs of ownership/ && giving back. On Tue, Sep 22, 2009 at 12:33 PM, Yioryos Asprobounitis <[email protected]> wrote: > Now, that's an excellent idea! > However, the crucial thing before any extensive building/testing starts is to > address some major issues that would stop most people from using/testing > F11/Sugar.84+. Namely the Xorg geode video driver, the camera and the battery > monitor. These will primarily need developers. > Having these components in place then a daily build bug fixing/reporting > system would be more valuable since more people may be willing to give it a > try, identifying the "minor" issues that may eventually allow a > deployment-quality release. > If this is going to be an OLPC, Fedora or SL project, I think is irrelevant. > XO-1 is an EOL machine that runs an OS/UI developed by "some other" > organization. Is literally orphan (besides these limited efforts) so any > "adopter" should be welcome. Whoever sets it up should be good to go. With > almost a million users is the biggest educational linux/sugar implementation > and worths every attention. > > --- On Mon, 9/21/09, David Farning <[email protected]> wrote: > >> From: David Farning <[email protected]> >> Subject: Re: XO Special interest group at Sugar Labs >> To: [email protected] >> Cc: "iaep" <[email protected]> >> Date: Monday, September 21, 2009, 7:36 PM >> On Mon, Sep 21, 2009 at 3:41 PM, >> Peter Robinson <[email protected]> >> wrote: >> > Hi David, >> > >> > On Mon, Sep 21, 2009 at 7:48 PM, David Farning <[email protected]> >> wrote: >> >> For the past several months the OLPC/Sugar Labs >> ecosystem has been >> >> getting requests to provide releases of more >> recent versions of Sugar >> >> on the XO. >> >> >> >> The leading effort in this direction seems to be >> the F11-XO1 project. >> >> I would like to like to invite F11-XO1 to become >> part of the XO SIG. >> >> I have been trying to articulate the project goals >> and gather momentum >> >> across several groups. >> >> 1. OLPC as a downstream. >> >> 2. Sugar Labs as a focus point. >> >> 3. Various ecosystem leaders to do pilots with >> current versions of Sugar on XOs. >> >> 4. Various testers to provide user level testing. >> >> >> >> The goal of this groups is not to _fragment_ the >> existing efforts. >> >> The goal is bring the various efforts together to >> form a critical mass >> >> to help pull this propel forward. >> > >> > As far as I'm aware there is no F11-XO1 project, I'm >> aware of a couple >> > of different projects to get the latest Sugar releases >> on the XO. >> > - The SoaS on XO which is being run my Martin Dengler >> in conjunction >> > with SoaS and SL (that's where its all hosted). >> > - The OLPC project to get Fedora 11 on both the XO-1.5 >> and XO-1 which >> > is being handled by Steven M. Parrish (and Daniel >> Drake / Chris Ball) >> >> This confusion is part of what I am hoping to clear up by >> create a >> single clearly defined project. >> >> I have heard back from many of the people working on the >> various >> projects. the work flow seems to be: >> 1. Sugar development team creates platform. >> 2. Fedora packagers package Sugar... and everything else >> required to >> make a disto. >> 3a. SoaS takes packages and turns them into a Soas image. >> 3b. Soas is getting pretty well test via test days and >> deployments >> such as the GPA. >> 4a. Steven take the Fedora packages adds the XO specific >> bit and turns >> them into xo builds. >> 4b. limited testing for xo builds. >> >> Because of time restrictions, the F11 on XO effort seems to >> be >> reactive. They take the output from cjb and the >> fedora packages and >> create builds. I believe that the XO SIG could help >> generate interest >> and attract more developers and testers to the project. >> >> > Both projects are cross pollinated and use components >> of work done by >> > both as well as myself and other Fedora upstream >> people. I don't >> > believe there's much difference between them as where >> possible I >> > believe most stuff is pushed upsteam. There is no >> current Fedora based >> > project working on this directly due to the down >> stream projects. >> > >> > I have my own build that I use but that isn't >> generally published and >> > is mostly to test core fedora for dependency bloat and >> breakages. >> >> Would it be useful if we started by combining your work and >> Stevens >> into an automatic build system. This could help >> identify breakages. >> Then we could create a release cycle of alpha and beta and >> final >> releases. >> >> By creating the daily builds and widely broadcasting the >> various >> releases, we can engage a larger community of testers. >> >> david >> >> _______________________________________________ >> Fedora-olpc-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/fedora-olpc-list >> > > > > > _______________________________________________ > Fedora-olpc-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > -- DancesWithCars leave the wolves behind ;-) _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
