Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, Mar 22, 2010 at 7:38 AM, Tomeu Vizoso wrote: > On Mon, Mar 22, 2010 at 11:51, Bernie Innocenti wrote: >> On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: >>> Agreed. You can do what you are doing (run a school on newish sw, get >>> a tight feedback & bugfix loop) when someone like you is there. >> [...] >>> Yes -- but we gotta remember that it's productive (specially for >>> Sugar) because you are there. You can turn their frustration into >>> valuable info (and bugfixes). Without you, it's just frustration. >> >> Indeed :-( >> >> I'm trying to get everyone on IRC and mailing lists before I leave. In >> Nepal it worked, but here the language barrier is higher. >> >> I told everyone that Spanish is welcome in bug reports, blog posts and >> for chatting on #sugar. Many of our core developers speak Spanish >> fluently, so they could bridge information to the others. >> >> Admittedly, it's not working: people come to IRC, they see that everyone >> speaks English, and shy away. I don't believe in breaking the community >> apart in many per-language ghettos, but Spanish probably has enough >> critical mass to justify a #sugar-es (or #olpc-es) channel. > > I have invested efforts in the past in that direction, but they > haven't taken off. We have sugar-desarrollo and we used to have a > channel as well, but haven't seen much use. #olpc-paraguay seems active because it has a tangible purpose. I imagine the same is true for whatever channel developers use in .uy. Maybe we should encourage more local foci for the initial engagement? Invite promising new contributors to use the same channel as the developers supporting their deployment. Naturally the interesting discussing on #olpc-paraguay seem to spill over into #sugar (well, the occasional deliberate push by Bernie or Raul helps). We will eventually figure this out :) -walter > If we had a deployment team, we could try to make a push so that > people from different deployments talk together in an open space... > > Regards, > > Tomeu > >>> That's a good idea -- try to work in a school with "latest" Sugar late >>> in the previous school year, to incorporate stuff for the wider >>> deployment in the over-summer-holidas upgrade. >>> >>> (And actually we have a late-starting deployment in La Rioja, which is >>> on-time to take advantage of that work.) >> >> Cool! A lot of stuff is moving forward here: >> >> * This Monday we'll have another meeting with the "formadores" to help >> them file complete and understandable bug reports without the need >> for us to go on-site. >> >> * We're now tracking the remaining bugs here: >> http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo >> >> * Two more developers of the Paraguay Educa technical team are learning >> to create OS builds. Next week, they'll start helping out with >> activities. >> >> * The formadores (teacher trainers) got used to the differences >> in the new software release and are no longer diffident. >> >> >>> That's truly a good question. I'll say "the teams closest to the >>> deployments". "Distant" upstreams (kernel, udev, Fedora) don't care >>> directly about our end users. OLPC/SLers are passionate about children >>> learning. >> [...] >>> Yep - that and combine it with working with a few schools on recent >>> releases, with a developer on-site -- like you, Simon and others are >>> doing. >> >> Yes, we definitely need more errant developers! Since there's a limited >> amount of core developers in OLPC and SL, in the future we may want to >> encourage deployments to exchange developers. The Paraguayan team now >> employs hackers with two years of experience. The same is probably true >> in Uruguay. >> >> It would be great if one of them could travel to the fledgling >> Argentinian deployment and help them build capacity locally. A >> decentralized model of international collaboration would solve the >> scalability problem. >> >> >>> In practice, it probably means we'll be answering questions about any >>> release for about 1.5 to 2 years after the release date. >> >> Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle >> synchronized across all the enterprise distributions: >> >> http://www.markshuttleworth.com/archives/290 >> >> If his proposal acquires enough momentum within the community, it would >> make sense for us to synchronize with it, solving the issue of being >> left behind by the rest of the development community. >> >> >>> N. I'm not so crazy. But we have to fit in the school's >>> 1-year-cycle, have time to stabilise, etc. Small deployments have more >>> flexibility, and when someone like you is literally on site you can go >>> wild... (take advantage of that!) but for the thousands of other >>> schools an LTS >> >> Testing and stabilize a new version of Fedora and Sugar on the XO could >> be done with as little as a few thousand students in a small town, with >> just 1-2 developers on site. >> >> After we're done with Sugar
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, Mar 22, 2010 at 11:51, Bernie Innocenti wrote: > On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: >> Agreed. You can do what you are doing (run a school on newish sw, get >> a tight feedback & bugfix loop) when someone like you is there. > [...] >> Yes -- but we gotta remember that it's productive (specially for >> Sugar) because you are there. You can turn their frustration into >> valuable info (and bugfixes). Without you, it's just frustration. > > Indeed :-( > > I'm trying to get everyone on IRC and mailing lists before I leave. In > Nepal it worked, but here the language barrier is higher. > > I told everyone that Spanish is welcome in bug reports, blog posts and > for chatting on #sugar. Many of our core developers speak Spanish > fluently, so they could bridge information to the others. > > Admittedly, it's not working: people come to IRC, they see that everyone > speaks English, and shy away. I don't believe in breaking the community > apart in many per-language ghettos, but Spanish probably has enough > critical mass to justify a #sugar-es (or #olpc-es) channel. I have invested efforts in the past in that direction, but they haven't taken off. We have sugar-desarrollo and we used to have a channel as well, but haven't seen much use. If we had a deployment team, we could try to make a push so that people from different deployments talk together in an open space... Regards, Tomeu >> That's a good idea -- try to work in a school with "latest" Sugar late >> in the previous school year, to incorporate stuff for the wider >> deployment in the over-summer-holidas upgrade. >> >> (And actually we have a late-starting deployment in La Rioja, which is >> on-time to take advantage of that work.) > > Cool! A lot of stuff is moving forward here: > > * This Monday we'll have another meeting with the "formadores" to help > them file complete and understandable bug reports without the need > for us to go on-site. > > * We're now tracking the remaining bugs here: > http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo > > * Two more developers of the Paraguay Educa technical team are learning > to create OS builds. Next week, they'll start helping out with > activities. > > * The formadores (teacher trainers) got used to the differences > in the new software release and are no longer diffident. > > >> That's truly a good question. I'll say "the teams closest to the >> deployments". "Distant" upstreams (kernel, udev, Fedora) don't care >> directly about our end users. OLPC/SLers are passionate about children >> learning. > [...] >> Yep - that and combine it with working with a few schools on recent >> releases, with a developer on-site -- like you, Simon and others are >> doing. > > Yes, we definitely need more errant developers! Since there's a limited > amount of core developers in OLPC and SL, in the future we may want to > encourage deployments to exchange developers. The Paraguayan team now > employs hackers with two years of experience. The same is probably true > in Uruguay. > > It would be great if one of them could travel to the fledgling > Argentinian deployment and help them build capacity locally. A > decentralized model of international collaboration would solve the > scalability problem. > > >> In practice, it probably means we'll be answering questions about any >> release for about 1.5 to 2 years after the release date. > > Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle > synchronized across all the enterprise distributions: > > http://www.markshuttleworth.com/archives/290 > > If his proposal acquires enough momentum within the community, it would > make sense for us to synchronize with it, solving the issue of being > left behind by the rest of the development community. > > >> N. I'm not so crazy. But we have to fit in the school's >> 1-year-cycle, have time to stabilise, etc. Small deployments have more >> flexibility, and when someone like you is literally on site you can go >> wild... (take advantage of that!) but for the thousands of other >> schools an LTS > > Testing and stabilize a new version of Fedora and Sugar on the XO could > be done with as little as a few thousand students in a small town, with > just 1-2 developers on site. > > After we're done with Sugar 0.84, I'll try to repeat the development > cycle for Sugar 0.88 and Fedora 12, starting with few adventurous > volunteers such as the Scratcheros. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, 2010-03-15 at 16:03 -0500, Martin Langhoff wrote: > Agreed. You can do what you are doing (run a school on newish sw, get > a tight feedback & bugfix loop) when someone like you is there. [...] > Yes -- but we gotta remember that it's productive (specially for > Sugar) because you are there. You can turn their frustration into > valuable info (and bugfixes). Without you, it's just frustration. Indeed :-( I'm trying to get everyone on IRC and mailing lists before I leave. In Nepal it worked, but here the language barrier is higher. I told everyone that Spanish is welcome in bug reports, blog posts and for chatting on #sugar. Many of our core developers speak Spanish fluently, so they could bridge information to the others. Admittedly, it's not working: people come to IRC, they see that everyone speaks English, and shy away. I don't believe in breaking the community apart in many per-language ghettos, but Spanish probably has enough critical mass to justify a #sugar-es (or #olpc-es) channel. > That's a good idea -- try to work in a school with "latest" Sugar late > in the previous school year, to incorporate stuff for the wider > deployment in the over-summer-holidas upgrade. > > (And actually we have a late-starting deployment in La Rioja, which is > on-time to take advantage of that work.) Cool! A lot of stuff is moving forward here: * This Monday we'll have another meeting with the "formadores" to help them file complete and understandable bug reports without the need for us to go on-site. * We're now tracking the remaining bugs here: http://wiki.paraguayeduca.org/index.php/Devel/Builds/Todo * Two more developers of the Paraguay Educa technical team are learning to create OS builds. Next week, they'll start helping out with activities. * The formadores (teacher trainers) got used to the differences in the new software release and are no longer diffident. > That's truly a good question. I'll say "the teams closest to the > deployments". "Distant" upstreams (kernel, udev, Fedora) don't care > directly about our end users. OLPC/SLers are passionate about children > learning. [...] > Yep - that and combine it with working with a few schools on recent > releases, with a developer on-site -- like you, Simon and others are > doing. Yes, we definitely need more errant developers! Since there's a limited amount of core developers in OLPC and SL, in the future we may want to encourage deployments to exchange developers. The Paraguayan team now employs hackers with two years of experience. The same is probably true in Uruguay. It would be great if one of them could travel to the fledgling Argentinian deployment and help them build capacity locally. A decentralized model of international collaboration would solve the scalability problem. > In practice, it probably means we'll be answering questions about any > release for about 1.5 to 2 years after the release date. Interestingly, Mark Shuttleworth has recently argued for a 2 years cycle synchronized across all the enterprise distributions: http://www.markshuttleworth.com/archives/290 If his proposal acquires enough momentum within the community, it would make sense for us to synchronize with it, solving the issue of being left behind by the rest of the development community. > N. I'm not so crazy. But we have to fit in the school's > 1-year-cycle, have time to stabilise, etc. Small deployments have more > flexibility, and when someone like you is literally on site you can go > wild... (take advantage of that!) but for the thousands of other > schools an LTS Testing and stabilize a new version of Fedora and Sugar on the XO could be done with as little as a few thousand students in a small town, with just 1-2 developers on site. After we're done with Sugar 0.84, I'll try to repeat the development cycle for Sugar 0.88 and Fedora 12, starting with few adventurous volunteers such as the Scratcheros. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, Mar 15, 2010 at 3:41 PM, Bernie Innocenti wrote: >> So no XS in place? > > The repair lab is not nearby any of the schools. Ah - ok. Thanks for clarifying. >> 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. Agreed. You can do what you are doing (run a school on newish sw, get a tight feedback & bugfix loop) when someone like you is there. > Letting volunteer children and teachers test the software has been > incredibly productive. Yes -- but we gotta remember that it's productive (specially for Sugar) because you are there. You can turn their frustration into valuable info (and bugfixes). Without you, it's just frustration. > 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. That's a good idea -- try to work in a school with "latest" Sugar late in the previous school year, to incorporate stuff for the wider deployment in the over-summer-holidas upgrade. (And actually we have a late-starting deployment in La Rioja, which is on-time to take advantage of that work.) > 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's fantastic. > Which dev team? That's truly a good question. I'll say "the teams closest to the deployments". "Distant" upstreams (kernel, udev, Fedora) don't care directly about our end users. OLPC/SLers are passionate about children learning. >> Yep. You could make it a "major / minor" pair. So you only have one >> LTS per year. > One year of slack between development and user release would be ideal. Yep - that and combine it with working with a few schools on recent releases, with a developer on-site -- like you, Simon and others are doing. In practice, it probably means we'll be answering questions about any release for about 1.5 to 2 years after the release date. > By LTS, I thought you meant 5 years :-) N. I'm not so crazy. But we have to fit in the school's 1-year-cycle, have time to stabilise, etc. Small deployments have more flexibility, and when someone like you is literally on site you can go wild... (take advantage of that!) but for the thousands of other schools an LTS cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Mon, 2010-03-15 at 10:46 -0500, Martin Langhoff wrote: > On Sun, Mar 14, 2010 at 1:17 AM, Bernie Innocenti 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/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Sun, Mar 14, 2010 at 1:17 AM, Bernie Innocenti 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? >> 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. Downstreams that go to deployment (OLPC!) want to wait until a release is reasonably well tested and stabilised. > 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!). > 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. 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. > 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". > 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. Yep. You could make it a "major / minor" pair. So you only have one LTS per year. "Developer" releases can happen more often. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On Sat, 2010-03-13 at 20:50 +, 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
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On 13 Mar 2010, at 18:12, Bernie Innocenti wrote: > On Sat, 2010-03-13 at 12:07 -0500, Martin Langhoff wrote: >> On Sat, Mar 13, 2010 at 11:50 AM, Bernie Innocenti >> wrote: >>> If you ask me: our recent F11-XO1 builds have reached equal or better >>> quality than build 801, provided you disable automatic power management. >> >> Are all activities working, including collaboration? In Gnome, can you >> actually use FF? Camera? > > >> >>> Hopefully, they will complain a little less on the next upgrade to 0.86 >>> and 0.88... Until they finally get used to the idea that software tends >>> to improve over time rather than getting worse. >> >> Or we slow down to a rhythm that they can cope with ;-)! > > Slowing down deployment of new versions might make things even worse! > > The more changes accumulate, the less familiar the new version will look > like, and the more time the users got to get used to the experience > provided by the old version, no matter how buggy it was. > > The Vista vs XP effect. > > The only way to reduce user adversity to change is getting them used to > smooth change by providing a short development cycle with few changes > that deliver clear improvements to the user experience in terms of new > features or fewer bugs. 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. 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? --G > The #1 bait we used to push this new release onto teachers was 3G > support. Suffice saying, GSM connectivity is very popular in places with > no wired broadband. > > Unfortunately, this wasn't quite true, bacause many popular Huawei > modems use by default a "Windows compatible" mode in which they show up > as mass-storage devices. After backporting udev to F-11, I found out > that now users are being sold an even newer model of Huawei modem which > is not yet supported by the Fedora 12 version of udev's rules. > > Teachers blamed the new Sugar for breaking their shiny new modems: they > seem unable to distinguish between a regression, a bug in new feature, > or an entirely missing feature. Heh... > > Anyway, now I found a temporary workaround and reported the missing > feature upstream: > > http://bugzilla.redhat.com/show_bug.cgi?id=573250 > > Too bad it was so easy: support for new devices would have maed a major > selling point for the next version of Fedora :-) > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
