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
Help with permissions under Rainbow sought
Hi all, I've been trying, in the last few days, to put the finishing touches on the PyDebug activity I have been developing. I am using an ipython console application which writes a history file to the home directory (I changed the HOME environment to SUGAR_ROOT/data). Rainbow changes UID for every invocation of the debugger so therefore the ability of ipython to update its history file would have to be based upon GID which is constant from one invocation to the next. Apparently the create mask rainbow uses is 755 and group members do not have write access. I came upon the strategy of having my program update the write permissions for group after every file creation so that full access would be available at the next invocation. But then I discovered that during execution, python creates the *.pyc files. If the process blows up before I have a chance to rewrite permissions, I will not be able to change the program and continue debugging. The only two solutions i've been able to come up with is to use supper user and the Terminal Activity to: 1. add 'org.laptop.PyDebug' to the list of programs for which rainbow is disabled in 'activityfactoryr' or 2. disable bitfrost entirely by renameing /etc/old-security. #1 seems much preferable, for XO1.5 and f11 for XO1.0. But it's kludgy for earlier builds. I don't know whether there are deployments that disable superuser in Terminal Application, which would make a patch impossible. Is there a solution Im missing? George ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] OLPC Moodle use
I would also point users to linux-for-education.org, which tries to be a little broader in terms of all the learning materials available, and isn't olpc centric. It does, however, have more olpc/sugar based learning materials than any other moodle install I know of. Having set up the majority of schools.sugarlabs.org and linux-for-education.org, I really think the 2 installs should be mirrors with the same content, to make it easier for content creators to choose where to deploy. Both sites have been neglected for quite a while, the main reason being I am the only one really paying any attention to deploying new learning materials, and I've been off doing other things, for which there seems to be a little more of a spotlight, something necessary, regardless of how selflessly time and energy is given to these projects. Unfortunately, since people don't seem to see the benefit of helping with the creation of documentation style learning materials, this is an uphill battle with no rewards. But we need this stuff, and even if its going to be just me adding content, then so be it, at least there is a place people can go to grab free in the full sense of the word learning materials. The sites (with an emphasis on linux-for-education.org) should be growing quite dramatically soon, due to needing to scratch our own itches (myself and some fellow users are starting up an IT school and are in need of free and open learning materials, so we will have to create what is not already there, ourselves) We will be basing the materials on ECDL and ICDL (European and Internatiohnal computer drivers license) as with that in mind one can get a diploma that is recognised in most places in the world. The ECDL curriculum is quite standardised and visible on its website, but there is still no location where one can download or interactively use the learning materials necessary to finally end up with the suite of diplomas available from ECDL. We hope to change this soon... kind regards, David Van Assche On Sat, Apr 17, 2010 at 2:56 AM, Frederick Grose fgr...@gmail.com wrote: On Fri, Apr 16, 2010 at 6:41 PM, David Leeming da...@leeming-consulting.com wrote: Is there an existing Wiki page where we can all add our contributions? This is a very good idea. I would suggest also some suggestions or approaches to training teachers to use it, i.e. a training curriculum introducing the features in a manageable way. For many of the teachers we deal with, the OLPC is their first experience with any type of computing. David Leeming One could demonstrate in the native format here, schools.sugarlabs.org/. That would remove a translation layer. There are, of course wikis available at http://wiki.laptop.org and http://wiki.sugarlabs.org where one could start a new page. --Fred *From:* server-devel-boun...@lists.laptop.org [mailto: server-devel-boun...@lists.laptop.org] *On Behalf Of *Luuk Terbeek *Sent:* Saturday, 17 April 2010 6:40 a.m. *To:* server-devel@lists.laptop.org *Subject:* [Server-devel] OLPC Moodle use Dear members of the server-devel@lists.laptop.org, Currently I'm preparing a presentation for the Dutch Moodle Moot. I hope to spread the word of the wonderful things that happen possibilities regarding the use of Moodle related to the OLPC project. For that reason I try to create an overview of best practices regarding the use of Moodle in the OLPC project. All your comments and suggestions are warmly welcome! Thanks in advance! Best regards, Luuk Terbeek ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
