Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Sat, Apr 17, 2010 at 2:52 AM, Bernie Innocenti ber...@codewiz.org wrote: On Fri, 2010-04-16 at 23:31 +0100, Peter Robinson wrote: [...] I'm not against packaging Sugar for RHEL. I just think it would cost more to support after the first year or two. Agreed. And in fact I said that exactly and hence my reference to the 18 month to 2.5 year point but the fact is by then you'll almost be to RHEL N+1 release so you role it over. Oh, now I get it. And I think I agree with you. The EL packaging makes it easy enough that its if it compile and there is demand for it then you can do so because to push it out isn't had if it stops compiling you send it out to the lists and either people care enough to fix the problem or else it stays on what ever the currently compiling version is. Sort of like the extended maintenance of the 0.84.x releases. Agreed here too (we're on the good way). Your making the problem like a Cross Road in a road. Its really not that. We are going to be following the upstream Fedora releases but I really don't think it will be hard to follow a RHEL release train either. In the F-7 to F-10 time frame the changes were massive. I know I had to assist in merging them upstream. But since then there's not been massive underlying changes that aren't manageable. The biggest I think are probably Tomeu's plans for the telepathy stuff and that is just to bring us back in line with the main line. I really hope you're wrong, but I'm afraid you're correct. We'd still have to change so much before Sugar becomes as mature and usable as Gnome is nowadays. Besides toemu's rewrite of the collaboration stack, there's Sascha's rewrite of the datastore still in the works. Yes, but I suspect that's more an internal change to the underlying structure and design rather than something that is going to require the latest and greatest library version X that's not released yet. I think the next big disruptive change will be python3 and associated pygtk changes, and while I don't have a crystal ball I think we can either stick with the current and it will be supported or there will be ways to support the new stuff. I'm not looking forward for Python 3. Every other large Python project has been procrastinating on this transition because there's not much to gain and a lot to loose. Yes, but its starting to pick momentum now. The first 3.x release is out fixing up some of the issues. Fedora 13 will have a python3 package and the python hack fest hosted at OLPC's office to bring up the gnome python bindings in preparation for gnome 3 also had quite a focus on support for python3 too, For us, switching to Python 3 would be unthinkably disruptive: half of the activities would remain broken for years, unless we maintain a Python 2 stack for backwards compatibility... /me shrugs And there is a perfect reason for a stable distro such as RHEL or CentOS :-) Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Sat, Apr 17, 2010 at 4:45 AM, Peter Robinson pbrobin...@gmail.com wrote: And there is a perfect reason for a stable distro such as RHEL or CentOS :-) :-) Two quick things I want to inject into this conversation. - Timing affects this decision. We're not in the abstract -- this is _now_. If RHEL6/CentOS6 is reasonably close to shipping on the target release date, I'd pick RHEL6 instead of F13/F14. Maybe a year or two later the base OS is F16. This is entirely pragmatic. - In my (fairly long) experience customising upstreams for deployment, once your upstream has the basics you need, it's _a lot_ less work to backport specific things you need than to re-base, re-test, re-stabilise all your work on top of a new release often. Specially when your test surface is large. And ours is _huge_. Yes, backporting things is a pain, but it's visible and localised. And you know when you are done. Re-testing is a huge workload, and we're just not seeing it because very little of it is getting done. The test teams we have are good -- we'd just need 10x of them! So many bugs that come from library changes (churn) are not being found, reported or fixed; and this has very low visibility, and hard to measure completion. Earlier (F7, F9), stable-ish upstreams didn't have what we needed, so Fedora's bleeding edge approach was crucial. When RHEL6/CentOS comes out, that game changes profoundly. 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: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Tue, 2010-04-13 at 07:59 +0100, Peter Robinson wrote: I agree on this, but it misses the point :-) Not exactly. That was just supposed to continue your point-point-point pun :) * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores RH updates those sort of components regularly to ensure support. This isn't a trivial bugfix or a matter of a missing product ID. It's an entire missing subsystem. I asked Harald Hoyer, the maintainer of udev, if there was a way to back-port the mode switch functionality from F12 to F11 and he told me good luck with it. * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs That is not due to up to date codecs but rather patent free codecs. Completely different issues. That is as valid with F-13 today as RHEL-5 RPM Fusion does indeed support RHEL5, but that's quite surprising. Enterprise distros have a tiny user base relative to the mainstream ones and tend to be badly supported even by proprietary software vendors such as Skype and Adobe. * activities such as Record tend to uncover obscure bugs in GStreamer Nothing stopping these being fixed in RHEL/CentOS. Nothing stops bugs from being fixed on Red Hat 7.2 either, as long as you're willing to invest your own time to do it. * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable RHEL updates this regularly as well and actively moves to the current version. I believe RHEL-5 has firefox 3.5 Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on which we depend for hulahop (and hence Browse). If adding features incrementally without ever breaking the ABI was feasible, the mainstream distros would do it as well. * ...not to mention NetworkManager... Mention what about it? We don't use any of the latest NM features, its stable and the maintainer actively assists and accepts patches. Stable?!? See this thread (it's broken up across 3 months in the pipermail archives): http://lists.laptop.org/pipermail/devel/2010-February/thread.html#27505 Besides this one, there were also other problems. I'd say NM was a major headache for this development cycle. In fact alot of the differences in packages were merged back in by me in the F-10/F-11 timeframe. I'm well aware of those issues, I still track them closely. I just wish it was the same with the kernel :-) Sorry, I totally forgot about the awesome work you had done for upstreaming OLPC changes into Fedora. 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. One word. PackageKit. Then its agnostic for all the distributions. +1 from me, but many Sugar developers wish to maintain the status quo. It's been discussed many times in the past. Unless the distributors take the initiative to do the work, it looks like native packaging formats aren't going to be supported by Sugar anytime soon. You've obviously not dealt with them then on the RHEL side of things. I work for a company that had over 1200 RHEL systems. Are we talking about paid support or free support? I'm sure you can get RH to fix any bug if you purchase 1200 RHEL licenses from them. There are advantages to both approaches and I don't see that supporting both is going to be an issue to do so at least in the short term. I don't see that we need to rule out either option. I'm not against packaging Sugar for RHEL. I just think it would cost more to support after the first year or two. -- // 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: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
--- On Fri, 4/16/10, Bernie Innocenti ber...@codewiz.org wrote: From: Bernie Innocenti ber...@codewiz.org Subject: Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119) I'm not against packaging Sugar for RHEL. I just think it would cost more to support after the first year or two. But at least you have 2 years. With F11 you have 0. Is there any reason on whu you think that rebasing every 12-18months will actually be less of a problem/cost? -- // 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: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Fri, 2010-04-16 at 14:00 -0700, Yioryos Asprobounitis wrote: But at least you have 2 years. With F11 you have 0. I agree. Today we should be releasing a system based on F13, which would come with 12 months of official support and maybe 8-10 months of *real* attention of the upstream developers of the OS components we rely upon. Is there any reason on whu you think that rebasing every 12-18months will actually be less of a problem/cost? Because rebasing on a new OS is not as expensive as fixing all bugs on your own. Moreover, soon or later you'd have to rebase anyway. The more you wait, the harder it gets. -- // 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: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Fri, Apr 16, 2010 at 9:20 PM, Bernie Innocenti ber...@codewiz.org wrote: On Tue, 2010-04-13 at 07:59 +0100, Peter Robinson wrote: I agree on this, but it misses the point :-) Not exactly. That was just supposed to continue your point-point-point pun :) * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores RH updates those sort of components regularly to ensure support. This isn't a trivial bugfix or a matter of a missing product ID. It's an entire missing subsystem. I asked Harald Hoyer, the maintainer of udev, if there was a way to back-port the mode switch functionality from F12 to F11 and he told me good luck with it. Yes, but usb_modeswitch works quite well. There's been a lot change since RHEL 5 was released about 3 years ago. I think RHEL-6 will be somewhat more easy in that regard because a lot of the building blocks that weren't in place 3 years ago are now. * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs That is not due to up to date codecs but rather patent free codecs. Completely different issues. That is as valid with F-13 today as RHEL-5 RPM Fusion does indeed support RHEL5, but that's quite surprising. Enterprise distros have a tiny user base relative to the mainstream ones and tend to be badly supported even by proprietary software vendors such as Skype and Adobe. Hmm. Skype isn't what I would call an enterprise product. If you want enterprise VoIP you'd use enterprise. Adobe still support acroread etc on RHEL-4! * activities such as Record tend to uncover obscure bugs in GStreamer Nothing stopping these being fixed in RHEL/CentOS. Nothing stops bugs from being fixed on Red Hat 7.2 either, as long as you're willing to invest your own time to do it. Yes, but being supported on the enterprise product means its more likely to be fixed in their stream. It also gives you a more stable environment rather that something that is like running across jelly. * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable RHEL updates this regularly as well and actively moves to the current version. I believe RHEL-5 has firefox 3.5 Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on which we depend for hulahop (and hence Browse). Yes, but we would have packages in the later versions of fedora that would support the later ABI of the newer versions of firefox that we would be able to compile against it so that isn't a major problem. One of the advantages of following both release trains. If adding features incrementally without ever breaking the ABI was feasible, the mainstream distros would do it as well. See point above. * ...not to mention NetworkManager... Mention what about it? We don't use any of the latest NM features, its stable and the maintainer actively assists and accepts patches. Stable?!? See this thread (it's broken up across 3 months in the pipermail archives): http://lists.laptop.org/pipermail/devel/2010-February/thread.html#27505 umm we're talking RHEL or a RHEL derived distro. That side will be stable. and the core components of NM are stable. The thread that you reference from the quick read I had was due to instability in the driver that was worked around in NetworkManager so that can only talk up not down NM support! Besides this one, there were also other problems. I'd say NM was a major headache for this development cycle. Really? I bet it was more the underlying driver issues that were more the case. Almost all of the issues I have wit NM ultimately are the drivers not NM at all. In fact alot of the differences in packages were merged back in by me in the F-10/F-11 timeframe. I'm well aware of those issues, I still track them closely. I just wish it was the same with the kernel :-) Sorry, I totally forgot about the awesome work you had done for upstreaming OLPC changes into Fedora. :-) 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. One word. PackageKit. Then its agnostic for all the distributions. +1 from me, but many Sugar developers wish to maintain the status quo. It's been discussed many times in the past. Unless the distributors take the initiative to do the work, it looks like native packaging formats aren't going to be supported by Sugar anytime soon. People are slowly coming around, and I'm slowly bribing people :-D You've obviously not dealt with them then on the RHEL side of things. I work for a company that had over 1200 RHEL systems. Are we talking about paid support or free support? I'm sure you can get RH to fix any bug if you purchase 1200 RHEL licenses from them. We pay for support (RHEL you need
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on which we depend for hulahop (and hence Browse). I had zero problems running Firefox 3.5 from the Terminal activity on my XOs. I am currently running Firefox 3.6.3 - again, zero problems - including being able to launch it from an icon within Home View. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Fri, 2010-04-16 at 23:31 +0100, Peter Robinson wrote: [...] I'm not against packaging Sugar for RHEL. I just think it would cost more to support after the first year or two. Agreed. And in fact I said that exactly and hence my reference to the 18 month to 2.5 year point but the fact is by then you'll almost be to RHEL N+1 release so you role it over. Oh, now I get it. And I think I agree with you. The EL packaging makes it easy enough that its if it compile and there is demand for it then you can do so because to push it out isn't had if it stops compiling you send it out to the lists and either people care enough to fix the problem or else it stays on what ever the currently compiling version is. Sort of like the extended maintenance of the 0.84.x releases. Agreed here too (we're on the good way). Your making the problem like a Cross Road in a road. Its really not that. We are going to be following the upstream Fedora releases but I really don't think it will be hard to follow a RHEL release train either. In the F-7 to F-10 time frame the changes were massive. I know I had to assist in merging them upstream. But since then there's not been massive underlying changes that aren't manageable. The biggest I think are probably Tomeu's plans for the telepathy stuff and that is just to bring us back in line with the main line. I really hope you're wrong, but I'm afraid you're correct. We'd still have to change so much before Sugar becomes as mature and usable as Gnome is nowadays. Besides toemu's rewrite of the collaboration stack, there's Sascha's rewrite of the datastore still in the works. I think the next big disruptive change will be python3 and associated pygtk changes, and while I don't have a crystal ball I think we can either stick with the current and it will be supported or there will be ways to support the new stuff. I'm not looking forward for Python 3. Every other large Python project has been procrastinating on this transition because there's not much to gain and a lot to loose. For us, switching to Python 3 would be unthinkably disruptive: half of the activities would remain broken for years, unless we maintain a Python 2 stack for backwards compatibility... /me shrugs -- // 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: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 09:31:25PM -0400, Bernie Innocenti wrote: On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. I agree on this, but it misses the point :-) I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. That's what I'm feeling all time started from the first time of my participating in sugar when I packaged sugar for several distros. Here are some real-world examples from this development cycle: * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs * activities such as Record tend to uncover obscure bugs in GStreamer * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable * ...not to mention NetworkManager... I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. and thats why I like 0install way - it is not tied to particular distro (packaging system) but can get benefits from all major distros (via PackageKit) and add distro agnostic packaging system. In my plans create distro agnostic sugar distribution entirely based on 0install - on most recent systems, users need only several clicks to install sugar w/o root privileges and even if sugar didn't packaged at all for this particular distro. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Tue, Apr 13, 2010 at 2:31 AM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. I agree on this, but it misses the point :-) Not exactly. I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. Here are some real-world examples from this development cycle: Agreed. * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores RH updates those sort of components regularly to ensure support. * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs That is not due to up to date codecs but rather patent free codecs. Completely different issues. That is as valid with F-13 today as RHEL-5 * activities such as Record tend to uncover obscure bugs in GStreamer Nothing stopping these being fixed in RHEL/CentOS. * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable RHEL updates this regularly as well and actively moves to the current version. I believe RHEL-5 has firefox 3.5 * ...not to mention NetworkManager... Mention what about it? We don't use any of the latest NM features, its stable and the maintainer actively assists and accepts patches. I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. You are not alone, you should see my BZ queue. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. In fact alot of the differences in packages were merged back in by me in the F-10/F-11 timeframe. I'm well aware of those issues, I still track them closely. I just wish it was the same with the kernel :-) 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. One word. PackageKit. Then its agnostic for all the distributions. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. You've obviously not dealt with them then on the RHEL side of things. I work for a company that had over 1200 RHEL systems. There are advantages to both approaches and I don't see that supporting both is going to be an issue to do so at least in the short term. I don't see that we need to rule out either option. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 11:12 PM, Bernie Innocenti ber...@codewiz.org wrote: On Sat, 2010-04-10 at 13:29 -0700, Jon Nettleton wrote: Has there been any discussion on whether CentOS was an option as a base for the distro? With RHEL/CentOS 6 hopefully within sight, that would give a nice target to provide both the combination of stability and long term support. This comes up every once in a while. Frankly, I don't believe in the value of enterprise Linux distributions; I've been stuck with them in a couple of cases in the past, and they were always a support PITA even for non-development usage: nobody in the community cares to help you with debugging and back-porting recent versions of software becomes increasingly painful over time. Granted, frequently upgrading the OS also comes with its own aches too, but these are amply compensated by useful new features and better support from upstream. We've been very lucky that Dan Williams was kind enough to spend some of his time for helping us with critical bugs in NetworkManager 0.7. We've not been equally lucky with udev and GStreamer, both of which have unsolved issues in F11 for which we lack expertise. Over the last 5 years, I've become a strong advocate of the decentralized, community-driven development model. I do believe in it because I've observed it at work for 15 years. Traditionally minded managers are still looking at this enormous market value accumulated by the open model as some sort of economic anomaly; some sort of prestige trick which contradicts the rules of classic schoolbooks. Yet, an entire industry of new businesses has grown out of free software and is flourishing with it. Those who guessed its rules can play the game and win. As Martin and I discussed not long ago, our development model doesn't have to directly affect end-users. Already released free software doesn't have an expiration date. Conservative users can keep using Sugar 0.82 forever, if they really like it better than newer releases. Bugfixes and new features could be back-ported from newer releases, of course with increasing costs as time passes. We OLPC Sugar developers cannot effectively support the entire codebase of an entire OS without strong backing from the larger Fedora community and the even larger global Linux community. In the past, Sugar and OLPC development was much hurt by its disconnection from the rest of the free software ecosystem on which it was built. We need to get much closer to our upstream projects, both in time (by using current software) and in space (by not diverging our codebase). It's not just a technological issue, it's a long-term sustainability issue. Before anyone yells Yarr! Ye don't care about the children!, I'd like to point out that I've been spending several months looking at problems in the field, trying to fix some of them and, more importantly, trying to build local capacity for fixing them autonomously. In my mind, this is *the only* reasonable strategy to scale Sugar support up to the size of an entire planet. Those who think it would be impossible for people in developing nations to learn the technical skills needed for fixing their software would be shocked to see what Nepal and Paraguay have been able to achieve in just two years, with very little funding. Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. Peter Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. I agree on this, but it misses the point :-) I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. Here are some real-world examples from this development cycle: * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs * activities such as Record tend to uncover obscure bugs in GStreamer * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable * ...not to mention NetworkManager... I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. -- // 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: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
IMHO I not only agree 120%, but also OLE Bolivia has budgeted support for upstreaming development. The idea being, if we are going to benefit, as an institution/country/project from work done professionally, if we are going to depend on it and expect it keeps up with improvements, then we have a duty to feed it, upstream, regularly. While an individual needs not be made responsible for that, I believe that any deployment above, say, 30-50 machines should consider helping fund development, at the local level especially, and have that development be made available to others. Deployments above the 1.000 units definitely can be counted as fair play when they have people on staff who are regularly connected with others worldwide in this effort. One of the uglier sides of piracy is that there is little sense of the duty to give back that has been built over the years. Hopefully we will get our project permitted to start sometime soon and we'll be able to contribute, as we have already benefited a lot from y'alls work. As Bernie says, there is a lot of skills out there, just waiting to be given a chance. Yama I've been spending several months looking at problems in the field, trying to fix some of them and, more importantly, trying to build local capacity for fixing them autonomously. In my mind, this is *the only* reasonable strategy to scale Sugar support up to the size of an entire planet. Those who think it would be impossible for people in developing nations to learn the technical skills needed for fixing their software would be shocked to see what Nepal and Paraguay have been able to achieve in just two years, with very little funding. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
