Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:24 AM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project Agreed on all of the above. And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC This is one of those steps that makes sense politically, but doesn't really pan out so well in practice. We really *do* need to have maintainability of a subset of activities. It's unfortunately that defining the set we want to 'own' gets people so flustered, but I still think we may find we need to make some form of commitment in this regard. 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time Yup. and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. I think we need to find a way to make solid, secure updates without wiping the machines clean each year; otherwise we're contradicting our goals for learning, as I see it. At the very least, end of year sounds like a good time to backup and organize all student data from the year somewhere (XS?). - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hi All, Responding to all in one pass. From Scott - The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. GS - Sounds good but it still requires all activity developers to update their activities which I think is the central problem. Also, we still need to warn users in advance, especially if they upgrade via USB. Definitely will help so let's do it if its not too much work. From Michael - 2 - Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions GS - How certain are these and is there any documentation of them or what activity changes they will require? We should agree that they are must have items worth requiring activity upgrade before doing them and we should document what it will cost activity developers if we do. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. and related comments GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. GS - I'm asking if we can tell developers here are the things you can do which will be safe. That is, make some kind of promise of backward compatibility for some subset of all functionality. http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html GS - Will read Monday, thanks. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? GS - I thought it was precise :-) and I meant not. I want to know if we can promise that *any* activities will continue to work. I hoped that these Sugar activities are the only ones using some APIs (e.g. collaboration) and therefore the only ones susceptible to breakage. In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). Again, please say more about what you're thinking of. GS - I'm saying let's make sure to discuss and agree before making any API changes that might break activities. Tuesday call? GS - Sorry I meant Tuesday software IRC/Gabble meeting. We are on for Tuesday and Wed. again this week at the same times, right? RE: Marco's comments. GS - Thanks! Can you start adding the names of all activities that we know should/will work to the Release notes too? How does someone know what version they have of an activity in Fructose or Glucose? Its helpful to claim backward compatible from Update.1. However, I believe many people will be upgrading from 656 too. Maybe we have to say: upgrade all your activities in that case? ** A few more questions on this: - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. - Black box testing of all activities is not feasible unless the authors do it themselves. Can we grep all the activity source code for the functions (or objects or whatever) that have changed and determine which activities might break? I haven't learned much about activity creation and bundling yet so pardon my ignorance if this is a naive question. Until we get a better grip on downstream relationships with activity authors I think the only short term answer is better documentation. Can someone put up a wiki page that explains what has changed and tells activity authors what
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 15:14, Greg Smith [EMAIL PROTECTED] wrote: GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. I've been thinking about having a mailing list specifically for activity authors. Many of them do not need all the info posted to devel@lists.laptop.org or [EMAIL PROTECTED], and may appreciate a specific list with lower noise (to them). The benefit to us would be a greater chance of reaching all activity developers. (Those who speak English, anyhow.) It should probably be on lists.sugarlabs.org, since activities are specific to Sugar. Any comments? - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. Uh, no, sorry to burst your bubble. N... (besides, why would you want to run your old version when you get fresh newness every +-6 months? :-) Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, 2008-07-14 at 09:14 -0400, Greg Smith wrote: - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. Upgrading a distribution is a very broad thing indeed. There are many components and considerations involved. I'm unable to think up any specific examples, but in general I think I disagree with your statement. Software that runs on one version of a distribution will be dependent on components which get upgraded/removed during the distribution upgrade, so in the end that piece of software will end up not working. The way that distributions get around this is by upgrading everything at once. In your example, staying with the old firefox would result in a broken firefox, but the distro upgrade software would make sure that it updates firefox to one compatible with the new distro components. You might not realise that Firefox got upgraded, it might look and feel identical to the old one, but it did. This is possible for distributions because both firefox (the application) and it's dependencies (underlying libraries etc) are all under control of one entity: the package manager. This isn't true in our case, where libraries are controlled by the rpm/yum package manager, but applications (activities) are not. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. If schools agree that this a good idea (it also wipes all the data and provides students with a lot more room); then what I would push for is that saved data can continue to work on upgraded activities -- this is something that the activity developers have to worry about, but it decreases the test effort quite a bit and recommends that schools retest activities between school years. Kim On Mon, Jul 14, 2008 at 9:14 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Responding to all in one pass. From Scott - The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. GS - Sounds good but it still requires all activity developers to update their activities which I think is the central problem. Also, we still need to warn users in advance, especially if they upgrade via USB. Definitely will help so let's do it if its not too much work. From Michael - 2 - Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions GS - How certain are these and is there any documentation of them or what activity changes they will require? We should agree that they are must have items worth requiring activity upgrade before doing them and we should document what it will cost activity developers if we do. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. and related comments GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. GS - I'm asking if we can tell developers here are the things you can do which will be safe. That is, make some kind of promise of backward compatibility for some subset of all functionality. http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html GS - Will read Monday, thanks. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? GS - I thought it was precise :-) and I meant not. I want to know if we can promise that *any* activities will continue to work. I hoped that these Sugar activities are the only ones using some APIs (e.g. collaboration) and therefore the only ones susceptible to breakage. In the future if
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
2008/7/14 Kim Quirk [EMAIL PROTECTED]: I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project Agreed on all of the above. And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC This is one of those steps that makes sense politically, but doesn't really pan out so well in practice. We really *do* need to have maintainability of a subset of activities. It's unfortunately that defining the set we want to 'own' gets people so flustered, but I still think we may find we need to make some form of commitment in this regard. 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time Yup. and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. I think we need to find a way to make solid, secure updates without wiping the machines clean each year; otherwise we're contradicting our goals for learning, as I see it. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:35 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 4:24 PM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. What if the web interface to the backups in the school server is as good or better than the local journal? Does it change any bit this issue? Sure. I'd love to see a really good backup solution that works seamlessly with the new Journal. In a sense, my point is that this is supposed to happen over time, just as memories fade over time. Perhaps we'll want to distort time a bit at the end of a school year and shove, say, enough of the Journal into backup to free up 1/2 the space on the laptop, but requiring manual restore (and access to the school server) every time a kid wants anything from the previous year sounds a bit frustrating to me, however good the UI is. More importantly, though, this backup solution doesn't solve other issues such as, for instance, my groups, my friends, my settings, and my installed activities. Regardless of what activities the school clean updates/installs, if a kid downloaded This or That, I think that should remain on the machine. We need to make sure, of course, that we a) provide an easy to use update system with notification, in case it's been updated to work with the newer OS b) gracefully handle failure of activities (the current timeout is poor). If the backup has some extra magic that can be used to automatically restore installed activities, friends, groups, setttings, etc., then we're just mixing terminology. That's not a clean install, but an upgrade install which is designed to keep user settings and files intact across the upgrade. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hmmm... I'm not sure that we have to lose all the information just becuase we did a clean install. If the backup of user data can be recovered (especially on a file by file basis). Don't we keep the meta data, so if the user choose to bring those items back into their laptop don't they still have date and time stamps, etc.? Kim On Mon, Jul 14, 2008 at 10:35 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 4:24 PM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. What if the web interface to the backups in the school server is as good or better than the local journal? Does it change any bit this issue? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:02 AM, Kim Quirk [EMAIL PROTECTED] wrote: Hmmm... I'm not sure that we have to lose all the information just becuase we did a clean install. If the backup of user data can be recovered (especially on a file by file basis). Don't we keep the meta data, so if the user choose to bring those items back into their laptop don't they still have date and time stamps, etc.? I feel like my previous message covered most of the points you ask about. 1) As great as the backup system may be (and I hope it is!), it's still unnecessary and suboptimal to require *anything* that was in a child's Journal require a manual backup step to use, and especially so because that requires access to the school server. Consider, for instance, a child at home who needs to look at a document from last year to inform her completion of tonight's homework assignment. Backups should be happening on the order of daily anyway, and entries should fall off over time anyway; the only thing we might want to do with the backup system is drop off a larger portion near the end of the school year (say, 1/2 the capacity) to make room for lots more stuff over the summer and following year. This should still use some heuristics (starred items, frequency of use, recency of use, etc) to determine what should go and what should stay. 2) Like I mentioned, I don't think the current backup solution really handles /installed/ activities, groups, friends, or settings at present. Perhaps we should start thinking about how it could; I'm not sure. All of these things should remain constant across the upgrade. If this is what you feel as well, I have no argument. =) I merely point out that this is NOT a clean install, and we shouldn't refer to it as such. It's a smart upgrade which retains user settings and (at least most) data. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I also disagree: this is unnecessary and eliminates the benefit of being able to roll back to your previous system if your upgrade broke something -- which you might not find out about until months later, potentially. The other points sound reasonable. I think we need to include a 'contact email' field in the activity.info for each activity (i'm kinda shocked we haven't done so yet) so that we can get in touch with maintainers, and then write a more rigorous guide to testing your release before deployment which helps countries go through the steps necessary to qualify the release + activities before they put it in a school. We need to allow local creation and maintenance of activities: OLPC can't hope to write all the needed activities itself. But at the same time we need to empower the countries to set standards of quality and kick the butts of activity authors if needed to get fixes made. If the activity is written under contract by the MoE, for example, then they should have a process/contract in place for revalidating and potentially patching it each year. (Hopefully improving it, too, not just maintaining it in stasis.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:22 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: The other points sound reasonable. I think we need to include a 'contact email' field in the activity.info for each activity (i'm kinda shocked we haven't done so yet) so that we can get in touch with This is something I brought up recently in another context. I think such a contact email would be really beneficial so, for instance, the Log activity can actually send logs to the people who actually care when that button is pressed. The problem with this design, of course, is that it exposes the email in a place where spammers can easily find it. This is really of concern mostly because we expect kids to create and maintain activities eventually as well. Of course, assuming the kids have an email account at all to provide, there's surely no way to prevent them from being spammed at all...should the field be optional? optional unless under contract? - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:32 AM, Eben Eliason [EMAIL PROTECTED] wrote: when that button is pressed. The problem with this design, of course, is that it exposes the email in a place where spammers can easily find Yes, that is life in the 200x's. Every major package management system has this feature. Deal with it tune your filters. it. This is really of concern mostly because we expect kids to create and maintain activities eventually as well. Of course, assuming the No one's forcing the kids to provide email addresses. We're just strongly suggesting that activities which are maintained by someone (either by OLPC for G1G1 or by countries for their deployments) have working addresses. Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. kids have an email account at all to provide, there's surely no way to prevent them from being spammed at all...should the field be optional? optional unless under contract? It is optional, but its presence should be noted as one of the positive factors when evaluating whether an activity you wish to include in your deployment is high quality. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 6:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. I suppose some activity authors might prefer to provide a link to some web page with the contacts... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 6:37 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 6:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. I suppose some activity authors might prefer to provide a link to some web page with the contacts... Cannot amo (addons.mozilla.org) handle this issue? David Farning is working on it, but it's a big task and could use some help. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 12:37 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 6:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. I suppose some activity authors might prefer to provide a link to some web page with the contacts... And I'd strongly prefer that they *not* do so. First off, it's pointless to do so, since the web page is a lot easier to spam-spider than the activity bundle. But fundamentally, I want to be able to use semi-automated tools to email all G1G1 activity authors, and having to trawl through web pages to find where the email addresses have been hidden is not my idea of a good time. The activities database at http://wiki.laptop.org/go/Activities already has a 'source url' field for the web page. What is needed is a means to (a) contact the maintainers, and (b) report bugs. A webpage URL does neither of these things. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 3:14 PM, Greg Smith [EMAIL PROTECTED] wrote: RE: Marco's comments. GS - Thanks! Can you start adding the names of all activities that we know should/will work to the Release notes too? I can add the Fructose ones, where are the release notes? :) How does someone know what version they have of an activity in Fructose or Glucose? By looking at the Sucrose release notes. (This is not the case for the release notes we made so far, because they only include the changed modules, I'll make sure it's the case for the next release). Its helpful to claim backward compatible from Update.1. However, I believe many people will be upgrading from 656 too. Maybe we have to say: upgrade all your activities in that case? Yeah, I don't think there is a way around that. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:49 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: And I'd strongly prefer that they *not* do so. First off, it's pointless to do so, since the web page is a lot easier to spam-spider than the activity bundle. But fundamentally, I want to be able to use semi-automated tools to email all G1G1 activity authors, and having to trawl through web pages to find where the email addresses have been hidden is not my idea of a good time. Different projects has different channels of communication, depending on the reason you are contacting them and the maintainer personal tastes. As an activity author I would not be comfortable about being contacted through semi-automated tools about bugs in my activity for example. Maybe it's just me... The activities database at http://wiki.laptop.org/go/Activities already has a 'source url' field for the web page. What is needed is a means to (a) contact the maintainers, and (b) report bugs. A webpage URL does neither of these things. It doesn't allow you to report bugs semi-automatically. But it certainly allows you to find out manually the bug tracker the project uses. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 5:24 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 10:49 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: The activities database at http://wiki.laptop.org/go/Activities already has a 'source url' field for the web page. What is needed is a means to (a) contact the maintainers, and (b) report bugs. A webpage URL does neither of these things. It doesn't allow you to report bugs semi-automatically. But it certainly allows you to find out manually the bug tracker the project uses. What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. Again, I would personally *hate* to receive these logs on my mail address or on the main mailing list of my project. They could be made available on a web site instead, or we could aim at integrating log with trac. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 11:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. Again, I would personally *hate* to receive these logs on my mail address or on the main mailing list of my project. They could be made available on a web site instead, or we could aim at integrating log with trac. GNOME, for example, has bug-buddy which reports crashes to bugzilla. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 5:39 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: They could be made available on a web site instead, or we could aim at integrating log with trac. GNOME, for example, has bug-buddy which reports crashes to bugzilla. The goal from the beginning has been to minimize cost-of-entry to develop applications for our platform. Requiring that people set up bugzilla in order to receive bug reports is a high bar! Requiring that they have an email address is not. By all means let's make our emails integrate nicely with bug reporting systems -- all sane bug trackers have an email gateway. But let's not turn the horse tail first by forcing all our activity authors to implement the same or similar bug trackers. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:36 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 5:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 11:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. Again, I would personally *hate* to receive these logs on my mail address or on the main mailing list of my project. THEN SET UP A DIFFERENT MAILING LIST! or write a mail filter. or designate another person to monitor the mailing list. Or use mailinator and check it via RSS on some schedule. A mailing list for random communications about my activity? No, thanks. I will simply not specify an email adress in the activity.info and ask people to report tickets through the project bug tracker. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:42 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: The goal from the beginning has been to minimize cost-of-entry to develop applications for our platform. Requiring that people set up bugzilla in order to receive bug reports is a high bar! Requiring that they have an email address is not. Not really if we provide something like track-hacks.org. By all means let's make our emails integrate nicely with bug reporting systems -- all sane bug trackers have an email gateway. But let's not turn the horse tail first by forcing all our activity authors to implement the same or similar bug trackers. I never said we should *not* support email. I said we should *also* support different communication means. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:05:46AM -0400, Daniel Drake wrote: On Mon, 2008-07-14 at 09:14 -0400, Greg Smith wrote: - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. Upgrading a distribution is a very broad thing indeed. There are many components and considerations involved. I'm unable to think up any specific examples, but in general I think I disagree with your statement. Software that runs on one version of a distribution will be dependent on components which get upgraded/removed during the distribution upgrade, so in the end that piece of software will end up not working. I disagree as well. Applications are fundamentally embedded within the system in which they run. This is particularly true within in the free / open source software environment in which our work is grounded. In such distributions, a specific version of a given application typically relies upon version ranges of various software libraries. These libraries encode systems which are required by the application but which are general enough that they may be used by multiple applications for different ends. Sharing code in this manner yields savings in terms of developer time and disk space, but it introduces a complex software dependency management problem. In practice, the complex interdependencies which arise due to this pattern of code sharing have encouraged the development of applications (the package managers) which automatically manage system upgrade and software installation by resolving dependencies between software packages. And in turn, the use of these systems has encouraged the process of code sharing by making commonly shared software libraries more accessible to developers. As Daniel notes, the package manager is the core software management entity in a typical distribution: On Mon, Jul 14, 2008 at 10:05:46AM -0400, Daniel Drake wrote: This is possible for distributions because both firefox (the application) and it's dependencies (underlying libraries etc) are all under control of one entity: the package manager. This isn't true in our case, where libraries are controlled by the rpm/yum package manager, but applications (activities) are not. ... Yet the barrier we have established between system and application prevents our utilization of such a system for software distribution management. We have attempted to structure our system such that applications are independent from the underlying operating system. We desire this distinction because it purportedly allows us to modularize user-level software systems into discreet non-interacting bundles, yielding benefits for system security and software distribution. In return for these benefits we must manage an optimization problem whose solubility decreases in step with the number of potentially useful activities developed for the XO. We must decide which libraries should be pulled from application-bundle into the system, and which should be pushed out of the system and into applications. Additionally, we must implement our own schemes to inform users of application / system compatibilities. (Note the concurrent thread on Activity versioning on the devel list.) We further isolate ourselves from our upstream distributions by requiring that every application be ported to our software distribution schema. We incur costs in creating our own custom solution to the problem of package management which handles software on one side of the application / system barrier. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Sat, Jul 12, 2008 at 12:56 AM, Greg Smith [EMAIL PROTECTED] wrote: I understand that we do not have backward compatibility in 8.2.0 as it currently stands. For Glucose we are supposed to be backward compatible with Update.1. ABI breaks should be reported as bugs. Can we bound the test problem by saying that all well behaved activities will continue to work? If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. We will work on ABI policy an document it, we will hopefully find time to introduce more automated testing. But at the speed of change of both Glucose and the distribution, I think it's impossible to say for sure if an activity will work without testing it. Bugs happens. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Do you really mean not there? In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). For Glucose that's already the case for Update-1 - 8.2.0. If something broke it's a bug. We don't have control on most of the distribution modules though, so I guess we will have to accept occasional breaks like the gtksourceview one. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Fri, Jul 11, 2008 at 06:56:35PM -0400, Greg Smith wrote: We should definitely have backward compatibility for activities! Your desire to maintain backwards compatibility for activities is a worthy goal but you need to be aware that there remain several areas in which we will likely break compatibility in order to carry on further development, both at the system and activity levels. Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions In each of these cases, we may have the ability to gradually deprecate old APIs by installing compatibility layers which implement them on top of new primitives. However, we will be well advised to carefully weigh the cost of maintaining these compatibility layers versus organizing the labor, as a community, necessary to port all the activities we can find to the new APIs. Michael A blow-by-blow: That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. In my opinion, we will simply have to include the cost of updating activities in our estimates of the cost required to deliver features which require API changes. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. It is also our responsibility to make breaking changes whenever doing so will improve the overall capability of children working with our software to learn. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. We mainly have bugs in 8.2.0. When we fix the bugs, we expect that we will have 'pretty good' compatibility at the API level. Obviously, there will be less compatibility at the UI level. Can we bound the test problem by saying that all well behaved activities will continue to work? Not really. What we _can_ do is to keep really good records of what activities are around and to invest in automated test facilities like tinderbox and sugarbot which might permit us to measure our compatibility status at an affordable cost. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. Any other suggestions on how to bound this test challenge appreciated! Titus Brown has written some persuasive arguments at http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html that I commend to your attention. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). Again, please say more about what you're thinking of. In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking things from the OS level. It's not prima facie much better to ensure compatibility AT THE COST of leaving critical features unimplemented. As with all things, we'll need to discuss it on a case-by-case basis. Let's talk more about this on the Tuesday call. Tuesday call? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Sat, Jul 12, 2008 at 00:56, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, We should definitely have backward compatibility for activities! In my opinion, there should be compatibility from one release to the next. APIs should not break from release to release unless critically necessary. If there is a new way of doing things which is better, the old way should still work - but it should warn in the log files that a deprecated API is being used. We should announce API deprecations - and API breaks where necessary - in advance of a new release (as well as release notes) so that activity authors are well aware of what is happening. This is done for Python releases, for example, giving people details on how to update python code from one version to another. Indefinite support of backwards compatibility certainly has been a major cause of platforms deteriorating (I'm thinking of Windows here). That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. 65x releases did not have Rainbow running, so activities could access and write to places on the filesystem which are no longer possible. For that reason we can only really focus on activities which already run on Rainbow. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. My understanding is that we made no particular guarantees, and while we did not intentionally break APIs, some things may have broken along the way. I think our development process should include some sort of compatibility management - perhaps as I mentioned above with API support between two consecutive releases - and this could be enforced or monitored with some sort of test activity (or test suite) that uses the various Sugar APIs and reports on failures. Can we bound the test problem by saying that all well behaved activities will continue to work? Unfortunately I think our APIs are insufficiently documented (or have been) so that even core activities are not guaranteed to be well behaved. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. I think a better criteria would be responsive activity authors who make some kind of commitment to keep their activities up to date from release to release. I don't think we should spend resources testing arbitrary third party activities, but where we can maintain a responsive developer community we can include them in the process. Any other suggestions on how to bound this test challenge appreciated! e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Not all activities were updated in Sucrose release 0.81.4 - some were updated in previous Sucrose releases. The activities listed in http://wiki.sugarlabs.org/go/Modules are ones where the maintainers have agreed to use the Sucrose release cycle (and other conditions listed in http://wiki.sugarlabs.org/go/ReleaseTeam#New_activities). These are activities which the Sugar project lists as demo activities, and may or may not coincide with OLPC's deployed activities (in the long term, as other users of Sugar emerge) - but they are certainly candidates for OLPC's use. Thus I would say that activities *not* on that list are the ones that are *not* guaranteed to work with 8.2.0, because the authors did not step up and take an interest in the new release. In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). API breaks should be discussed during a development cycle as the need for them emerges, hopefully as early as possible in the cycle so there are no surprises. In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking things from the OS level. On the other hand, newer activities can require a newer OS. That can be handled if we have good activity documentation on the download and activity pages. Yes. You've been talking about running old activities on a new release - I would include new versions of activities here which may require a newer OS/release. Perhaps we should change the activity service name (e.g. org.laptop.Chat) when an activity is updated in such a way that it can no longer run on old releases. Perhaps that should also be done when a newer version of an activity can no longer collaborate with an older version. Sounds like we have a big activity test challenge ahead for 8.2.0... BTW is this the full list of all known
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On 7/12/08, Morgan Collett [EMAIL PROTECTED] wrote: On Sat, Jul 12, 2008 at 00:56, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, We should definitely have backward compatibility for activities! In my opinion, there should be compatibility from one release to the next. APIs should not break from release to release unless critically necessary. If there is a new way of doing things which is better, the old way should still work - but it should warn in the log files that a deprecated API is being used. Problems arise independently of API when libraries not part of the base system are used. For example, I have an activity that uses goocanvas and the glibmm libaries, which I package in the activity bundle. I tried first using glibmm from F9, but it didn't work on F7-based builds. I then substituted glibmm from F7, and it works on 656, 703/8, and all the recent joyrides. I don't know the best way to handle this generally, I suppose it is up to individual activity owners to make sure their stuff works all over. bobby We should announce API deprecations - and API breaks where necessary - in advance of a new release (as well as release notes) so that activity authors are well aware of what is happening. This is done for Python releases, for example, giving people details on how to update python code from one version to another. Indefinite support of backwards compatibility certainly has been a major cause of platforms deteriorating (I'm thinking of Windows here). That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. 65x releases did not have Rainbow running, so activities could access and write to places on the filesystem which are no longer possible. For that reason we can only really focus on activities which already run on Rainbow. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. My understanding is that we made no particular guarantees, and while we did not intentionally break APIs, some things may have broken along the way. I think our development process should include some sort of compatibility management - perhaps as I mentioned above with API support between two consecutive releases - and this could be enforced or monitored with some sort of test activity (or test suite) that uses the various Sugar APIs and reports on failures. Can we bound the test problem by saying that all well behaved activities will continue to work? Unfortunately I think our APIs are insufficiently documented (or have been) so that even core activities are not guaranteed to be well behaved. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. I think a better criteria would be responsive activity authors who make some kind of commitment to keep their activities up to date from release to release. I don't think we should spend resources testing arbitrary third party activities, but where we can maintain a responsive developer community we can include them in the process. Any other suggestions on how to bound this test challenge appreciated! e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Not all activities were updated in Sucrose release 0.81.4 - some were updated in previous Sucrose releases. The activities listed in http://wiki.sugarlabs.org/go/Modules are ones where the maintainers have agreed to use the Sucrose release cycle (and other conditions listed in http://wiki.sugarlabs.org/go/ReleaseTeam#New_activities). These are activities which the Sugar project lists as demo activities, and may or may not coincide with OLPC's deployed activities (in the long term, as other users of Sugar emerge) - but they are certainly candidates for OLPC's use. Thus I would say that activities *not* on that list are the ones that are *not* guaranteed to work with 8.2.0, because the authors did not step up and take an interest in the new release. In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). API breaks should be discussed during a development cycle as the need for them emerges, hopefully as early as possible in the cycle so there are no surprises. In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking
Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hi Guys, We should definitely have backward compatibility for activities! That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. Can we bound the test problem by saying that all well behaved activities will continue to work? If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. Any other suggestions on how to bound this test challenge appreciated! e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking things from the OS level. On the other hand, newer activities can require a newer OS. That can be handled if we have good activity documentation on the download and activity pages. Sounds like we have a big activity test challenge ahead for 8.2.0... BTW is this the full list of all known activities? http://wiki.laptop.org/go/Activities Let's talk more about this on the Tuesday call. Thanks, Greg S Chris Ball wrote: Hi, On Wed, 2008-07-09 at 21:06 +0200, Morgan Collett wrote: My 2c worth here... There haven't been API breaks for activities. I've had to do nothing to my activities to keep them working from 8.1.0 to joyride current. Some external things have bitten us though. gtksourceview API change prevents Pippy-20 from launching (that's the version installed by Bert's script, even today) http://dev.laptop.org/ticket/3488 And an Sugar API change caused Pippy to stop being able to build activities: http://dev.laptop.org/ticket/7205 - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
